launchpad-dev team mailing list archive

[Bjorn Tillenius <bjorn@xxxxxxxxxxxxx>]

Hi,

at the team lead sprint we discussed how we could solve the problem of
unfinished features being pushed out to launchpad.net every time we do a
release.

I have a proposal how we can keep the development cycle separate from
our montly "push out db changes" cycle. I think using branches to handle
this would work well, so I'm proposing how we could change our merge
worfklow to make things better. There are still a few unknowns, but
let's start a discussion of what I have so far, before I try to refine
it.

I've created a LPE, to see how that works, which describes why we're
doing this:

    https://dev.launchpad.net/LEP/ReleaseFeaturesWhenTheyAreDone

I've also started to document how the new process would work, which is
what I want comments on:

    https://dev.launchpad.net/MergeWorkflowDraft

There is a picture there, so I would advise you to look at the wiki
page, but I will include the text in this mail, to make it easier to
discuss.

I've chosen to include both the addition of a QA step before revisions
can be rolled out to production, and continuous rollouts to
launchpad.net. I think the QA step should remain, but we could choose
not to do continuous rollouts to begin with.

I'm away on Monday and Tuesday, but will be able to participate in the
discussion on Wednesday again. Francis might be able to clarify things,
even though I think this version of the proposal is a bit different from
what we have discussed. I'm very open to changes to the proposal that
reduces the complexity for the developers landing features.

Here's the text of 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.

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.

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.

{{attachment:merge-workflow.png}}

== The QA step ==

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.

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


-- 
Björn Tillenius | https://launchpad.net/~bjornt