launchpad-dev team mailing list archive

[Bjorn Tillenius <bjorn@xxxxxxxxxxxxx>]

On Fri, Feb 12, 2010 at 11:57:12AM -0500, Francis J. Lacoste wrote:
> On February 12, 2010, Bjorn Tillenius wrote:
> > 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
> 
> That link doesn't work for me.

Oops, seems I forget to actually save the page. It should work now.


> > 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.
> > 
> 
> I don't understand how you can land changes both bug fixes and feature 
> integration on the edge branch and how to deploy the QA revisions to 
> production. Bazaar doesn't support cherry-picking.

Right. I initially thought it would be ok, since usually bzr handles
that situation quite well. However, since we want to see which revisions
that haven't been pulled over yet, it won't work that well (unless we
keep track of it elsewhere).


> I think we need an intermediate branch (devel) on which we land simple bug 
> fixes, and any stretch of QA revisions on that branch can be merged to 
> production.
> 
> Edge would be the result of devel + features integration branches.

Yeah. I was hoping to avoid adding a new branch, since it complicates
things, but it looks like we have to.



> 
> > {{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.
> 
> A revision property?

I don't think this would work, since AFAIK, you can't really change
revision properties after they have been committed. Or can you?


> > == 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?
> 
> Again, since bazaar doesn't support revision cherry-picking, we probably need 
> separate branch. I heard that bzr-builder could be use to merge a set of 
> branches automatically.

Yes, might be possible to use bzr-builder, I haven't looked into that
yet.


> > == What about `staging.launchpad.net` ==
> > 
> > Staging takes the `edge` branch and merges in the `db` branch.
> > 
> 
> I don't think this works because edge contains feature branches that are not 
> ready for roll-out. I think we want staging to be exactly what will be rolled-
> out next month. So it should be the db branch + all the QA changes.

Ideally we should have both (one staging for lpnet and one for edge).
Staging is good for QAing the feature without modifying production data.



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