I want to enable developers to deploy their own code on their or their teams' own schedule. I think this change would make it easier for project management and for collaboration with QA and other stakeholders. Developers owning their code's entire lifecycle will help identify problems with the code more quickly since there will be fewer changes deployed at once. There will also be a lower chance of merging and forgetting that deployment happens at a later date.
Several changes would be required in our code review and deployment process.
Code review:
- Don't automatically submit a patch after +2 is given. We will treat +2 as "approve to merge/deploy"
- Merge is only enabled once a "deployer" role holder (and/or other role, this merge rule could be configured as desired) + CI have approved the patch.
With these changes, a patch can now be merged and deployed by any contributor at any time. Ability to merge and deploy could also be restricted to a role if desired, but allowing any contributor to merge and deploy would allow volunteers to get their code deployed faster once the patch has been approved.
Deployment
- Use long-lived branches. For example, one branch each for TestWikis, Group0, Group1, and all remaining Wikimedia wikis. Versions are no longer used by this process. I think this is the easiest way to transition although future states could have just one main branch and use other methods such as feature flags in order to select a group of wikis to deploy to.
- Patches are cherry-picked to be promoted to the next group when desired by the team/developer/product manager etc.
- Use continuous deployment. A merge will trigger a deploy. Question: How can we address any security concerns about approving patches and merging them?
- Should an issue occur, certain roles have the ability to pause deployments to each group.
I've also created an idea of a deployment dashboard that would be used to help deployments and see which patches are on which group.
I'd like to start a discussion on the ideas presented above!