MergeWorkflow

Not logged in - Log In / Register

Revision 12 as of 2010-07-13 08:14:27

Clear message

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 2

Branches that contain db changes land on the db branch, and are QA'd on staging. 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.

merge-workflow-draft-2.jpeg

Image source: merge-workflow-draft-2.jpeg

Merge Workflow Draft 1

To summarize, branches that contain db changes always get landed to the db branch. Bug fixes get landed to the stable branch, and larger features (consisting of multiple branches) get landed to an integration branch for that feature.

For bug fixes, the landed revision stays in the stable 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.

For larger features, the integration branch gets combined with stable, and rolled out to edge.launchpad.net daily. When the feature is done and QAed, it gets merged into the stable branch, and the merged revision finally gets merged into the production branch after it has been QAed again on staging.

merge-workflow.png

Image source: merge-workflow.dia

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.

XXX: How the QA step works regarding to marking the revision as good/bad is still undefined.

Feature branches

Features that will involve multiple branches should have an integration branch for that feature. Instead of landing branches related to the feature to stable, they land their branches to the integration branch. New revisions in the integration branch will automatically be merged 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 merging specific revisions into stable.

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 are already exposed on launchpad.net can go directly to the stable branch. After the revision has been QAed, it gets merged into the production branch.

When to use a feature branch

So far we've talked about features and bug fixes. However, all features don't need a feature branch. A feature branch is only necessary when you have a larger feature that will require multiple branches to complete. If you have a small feature, or improvement of an existing feature, that you're quite sure will require only one branch, landing it directly on the stable branch is fine.

Which branch should you branch off from when starting new work?

When starting new work, you should branch off from the db branch if your work will require db changes, and from the stable branch otherwise. You shouldn't start of from edge, since it contains features that shouldn't be rolled out to production yet, which means that you would have to wait for the existing features to be finished, before your feature can be considered for rollout.

If possible, the required db changes should go to the db branch one cyle in advance, to make it possible to QA the other work on edge.

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 uses the db branch, so that we can do final QA of what gets rolled out to launchpad.net. The stable branch gets automatically merged into the db branch, so that the revisions in the stable branch is testable on staging.