Change Details

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. When the developers own their code's entire lifecycle hopefully this will also help with identifying bugs and issues more quickly since there will be fewer numbers of changes being deployed at once, and the chance of merging and then moving on to the next task without remembering that deployment happens at a later date will be lower. 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 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 it has been approved. **Deployment** - Use long-lived branches. For example, one branch each for TestWikis, Group0, Group1, and all wikis. Versions are no longer used. I think this is the easiest way to transition although future states could possibly have just one master 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 concerns about security regarding the approval of patches and ability to merge them? - Should an issue occur, certain roles have the ability to pause deployments to each group. I've also sketched an idea of a deployment dashboard that would be used to facilitate deployments and see which patches are on which group. {F37659005} I'd like to start a discussion on the ideas presented above!

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. When the developers own their code's entire lifecycle hopefully this will also help with identifying bugs and issues more quickly since there will be fewer numbers of changes being deployed at once, and the chance of merging and then moving on to the next task without remembering that deployment happens at a later date will be lower. 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 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 it has been approved. **Deployment** - Use long-lived branches. For example, one branch each for TestWikis, Group0, Group1, and all wikis. Versions are no longer used. I think this is the easiest way to transition although future states could possibly have just one master 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 concerns about security regarding the approval of patches and ability to merge them? - Should an issue occur, certain roles have the ability to pause deployments to each group. I've also sketched an idea of a deployment dashboard that would be used to facilitate deployments and see which patches are on which group. {F37659008} I'd like to start a discussion on the ideas presented above!

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. When the developers own their code's entire lifecycle hopefully this will also help with identifying bugs and issues more quickly since there will be fewer numbers of changes being deployed at once, and the chance of merging and then moving on to the next task without remembering that deployment happens at a later date will be lower. 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 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 it has been approved. **Deployment** - Use long-lived branches. For example, one branch each for TestWikis, Group0, Group1, and all wikis. Versions are no longer used. I think this is the easiest way to transition although future states could possibly have just one master 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 concerns about security regarding the approval of patches and ability to merge them? - Should an issue occur, certain roles have the ability to pause deployments to each group. I've also sketched an idea of a deployment dashboard that would be used to facilitate deployments and see which patches are on which group. {F37659005}8} I'd like to start a discussion on the ideas presented above!