Diff for "MergeWorkflow"

Not logged in - Log In / Register

Differences between revisions 21 and 22
Revision 21 as of 2010-07-20 20:28:49
Size: 2732
Editor: mars
Comment:
Revision 22 as of 2010-07-22 14:51:59
Size: 2838
Editor: mars
Comment:
Deletions are marked like this. Additions are marked like this.
Line 13: Line 13:
are QA'd on staging. DB changes are rolled out monthly, as today. 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.

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.

mergeworkflow.png

(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.

MergeWorkflow (last edited 2010-11-08 22:01:23 by lifeless)