launchpad development|
Size: 2907
Comment:
|
Size: 1874
Comment: update
|
| 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 description of how a developer branch flows through the different 'official' branches we have, after the developer branch is ready for landing. |
| Line 3: | Line 4: |
| 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 = |
| Line 6: | Line 6: |
| 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. |
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 10: | Line 10: |
| {{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 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. {{attachment:mergeworkflow.png}} ''(Old image: [[attachment:merge-workflow-draft-2.jpeg]])'' |
| Line 14: | Line 22: |
| 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 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. |
| Line 18: | Line 25: |
| 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 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 21: | Line 28: |
| How the QA step works regarding to marking the revision as good/bad is described on [[QAProcessContinuousRollouts]]. | |
| Line 22: | Line 30: |
| == Feature branches == | === What if I don't do my QA, or my QA is bad? === |
| Line 24: | Line 32: |
| 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. == Bug fixes == 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. == Continuous rollouts to `launchpad.net` == 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`. We only do this for the web app servers, since we can update them without any downtime. 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. |
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 |
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
