launchpad development|
Size: 2953
Comment: Its a bit more than a draft now.
|
Size: 1874
Comment: update
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| ## page was renamed from MergeWorkflowDraft This is a proposal of how a developer branch flows through the different production branches we have, after the developer branch is ready for landing. |
This is a description of how a developer branch flows through the different 'official' branches we have, after the developer branch is ready for landing. |
| Line 6: | Line 4: |
| = Merge Workflow Draft = | = Merge Workflow = |
| Line 8: | Line 6: |
| Bugfixes land on the `stable` branch and are rolled out daily to a "QA testing" server for QA. Revisions that have been marked QA-OK are copied to a `production` branch and then rolled out daily to production and edge. |
Branches without db changes (or dependencies on pending db changes) land on the `stable` branch and are rolled out every 30 minutes to a "QA testing" server for QA. Revisions that have been marked QA-OK are [[https://devpad.canonical.com/~lpqateam/qa_reports/deployment-stable.html|eligible] for deployment. Deployment takes a specific revision of `stable` and deploys that to a named set of machines. The default set is `nodowntime` which encompasses all services that we can deploy to without user visible downtime. |
| Line 14: | Line 11: |
| are QA'd on staging. The `db-stable` branch merge automatically changes from `stable`, as happens today. DB changes are rolled out to production and rolled back into `stable` once a month, also as it happens today. |
are QA'd on staging. The `db-stable` branch automatically merges changes from `stable` via a push event in Buildbot. DB changes are rolled out to production and merged back into `stable` once a month. |
| Line 26: | Line 22: |
| A revision gets merged from `stable` to `production` only after it has been marked as good in the QA step. This helps ensure that we don't |
A revision gets deployed only after it has been marked as good in the QA step. This helps ensure that we don't |
| Line 30: | Line 25: |
| In addition to this, a revision only gets merged from `stable` to `production` if all the previous revisions have been marked as good as well. This is because bzr doesn't support cherry picking, and we want to keep track of which revisions have been merged. |
In addition to this, a revision only gets deployed if all the previous revisions have been marked as good as well. This is because cherrypicking can invalidate QA efforts when patches have non-obvious dependencies. |
| Line 40: | Line 33: |
| block production/edge rollouts until that revision is reverted. Rollouts from `stable` to the QA server will still continue, so other developers can still continue their QA as normal. We assume a two day grace period for QA - if on the third day a branch has not been QA'd, then anyone on the team may revert the offending revision. We must focus on making these reversions as easy and painless as possible. === What if I have to do QA that takes a few days? === If a feature requires more than one day of QA, then developers have the option to do the QA on the `staging.launchpad.net` server, to requisition an additional server, (dogfood), or ask for permission to block the daily QA rollouts for more than two or three days. == The Rollout == Rollouts of database changes still happen as before. == Large Features That Span Branches == If you have a feature that will span multiple branches, then it is expected that the developers will create a [[LEP/FeatureFlags|feature switch]] to optionally enable that part of the code, or that early branches that have no user-facing changes will be marked as `qa-untestable`. == Emergency Fixes/Cherry Picks == The cherry-pick procedure remains the same as it does currently - you must land the change on both the `production` branch and later on the `stable` branch. |
block deployments until that revision is reverted '''and''' the intervening revisions have also been QA'd. Rollouts from |
This is a description of how a developer branch flows through the different 'official' branches we have, after the developer branch is ready for landing.
Merge Workflow
Branches without db changes (or dependencies on pending db changes) land on the stable branch and are rolled out every 30 minutes to a "QA testing" server for QA. Revisions that have been marked QA-OK are [[https://devpad.canonical.com/~lpqateam/qa_reports/deployment-stable.html|eligible] for deployment. Deployment takes a specific revision of stable and deploys that to a named set of machines. The default set is nodowntime which encompasses all services that we can deploy to without user visible downtime.
Branches that contain db changes land on the db-stable branch, and are QA'd on staging. The db-stable branch automatically merges changes from stable via a push event in Buildbot. DB changes are rolled out to production and merged back into stable once a month.
(Old image: merge-workflow-draft-2.jpeg)
The QA step
A revision gets deployed only after it has been marked as good in the QA step. This helps ensure that we don't rollout feature to launchpad.net that haven't been QAed.
In addition to this, a revision only gets deployed if all the previous revisions have been marked as good as well. This is because cherrypicking can invalidate QA efforts when patches have non-obvious dependencies.
How the QA step works regarding to marking the revision as good/bad is described on QAProcessContinuousRollouts.
What if I don't do my QA, or my QA is bad?
If someone does not do their QA, or their branch fails QA, then they will block deployments until that revision is reverted and the intervening revisions have also been QA'd. Rollouts from
