launchpad development|
Size: 2907
Comment:
|
Size: 2838
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| 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 proposal of how a developer branch flows through the different production branches we have, after the developer branch is ready for landing. |
| Line 3: | Line 5: |
| To summarize, branches that contain db changes always get landed to the `db` branch. Other changes get landed to the `edge` branch, although branches that are part of a larger features (consisting of multiple branches) get landed to edge through an integration branch for that feature. |
= Merge Workflow Draft = |
| Line 6: | Line 7: |
| The landed revision stays in the `edge` branch until it has been marked as being QAed. When the revision is marked as good, it automatically gets merged into the `production` branch, which is rolled out to `launchpad.net` daily. |
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. |
| Line 10: | Line 12: |
| {{attachment:merge-workflow.png}} | Branches that contain db changes land on the `db-stable` branch, and are QA'd on staging. The `db-stable` branch is updated daily with changes from `stable`, as happens today. DB changes are rolled out monthly, also as it happens today. {{attachment:mergeworkflow.png}} ''(Old image: [[attachment:merge-workflow-draft-2.jpeg]])'' |
| Line 14: | Line 24: |
| A revision gets merged from `edge` to `production` 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. |
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 rollout feature to `launchpad.net` that haven't been QAed. |
| Line 18: | Line 28: |
| XXX: How the QA step works regarding to marking the revision as good/bad is still undefined. |
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. 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 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. |
| Line 22: | Line 47: |
| == Feature branches == | === What if I have to do QA that takes a few days? === |
| Line 24: | Line 49: |
| Features that will involve multiple branches should have an integration branch for that feature. Instead of landing branches related to the feature to `edge`, they land their branches to the integration branch. New revisions in the integration branch will automatically be merge into the `edge` branch. The reason for having an integration branch branch is to keep track of all the revisions that belong to the feature, so that when the feature has been marked as good in the QA process, the whole feature can be rolled out at once. Parts of the feature can still be rolled out by QAing specific revisions. XXX: How to register new feature branches, and how to merge to them, is still undefined. Maybe a better way would be to use revision properties to tag revisions as being part of a bigger feature, or use bug links? === Resolving conflicts === If there's a conflict when automatically merging the feature branch into the `edge` branch, someone has to manually merge the feature branch into `edge` and resolve the conflicts. |
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. |
| Line 43: | Line 55: |
| == Bug fixes == | == The Rollout == |
| Line 45: | Line 57: |
| Bug fixes for features that already exposed on `launchpad.net` can go directly to the `edge` branch. After the revision has been QAed, it gets merged into the `production` branch. |
Rollouts of database changes still happen as before. |
| Line 50: | Line 60: |
| == Continuous rollouts to `launchpad.net` == | == Large Features That Span Branches == |
| Line 52: | Line 62: |
| The `production` branch gets rolled out to the web app servers daily, to expose our users to bug fixes not too long after the fix has been verified to work on `edge.launchpad.net`. |
If you have a feature that will span multiple branches, then it is expected that the developers will create a 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`. |
| Line 56: | Line 67: |
| We only do this for the web app servers, since we can update them without any downtime. |
== Emergency Fixes/Cherry Picks == |
| Line 59: | Line 69: |
| XXX: If we're not ready for this, things could get merged into the `db` branch after being QAed, waiting to get rolled out with the next release. == What about `staging.launchpad.net` == Staging takes the `edge` branch and merges in the `db` branch. |
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. |
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.
Merge Workflow Draft
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 that contain db changes land on the db-stable branch, and are QA'd on staging. The db-stable branch is updated daily with changes from stable, as happens today. DB changes are rolled out monthly, also as it happens today.
(Old image: merge-workflow-draft-2.jpeg)
The QA step
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 rollout feature to launchpad.net that haven't been QAed.
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.
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 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 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.
