launchpad-dev team mailing list archive

["Francis J. Lacoste" <francis.lacoste@xxxxxxxxxxxxx>]

Hi Robert,

I think this concept is where we want to end up, but there is still a few 
gotchas to take care of.

The main one is that we do have more stuff landing in db-devel than we would 
hope for. Especially UI work that builds on top of model changes requiring a 
DB schema.

A good example is the subscription work that the Bugs team is doing this 
month. Abel is still finishing the DB patch for this and then I'd expect some 
UI and more model changes to build on top of that. That must remain in db-
devel until the schema change is deployed to production. When can still use 
feature flags for it so that if it's not fully bake at the next release, our 
regular users are not exposed to it. But we must still be able to bake it!

Stopping development of the UI and model changes until the schema have been 
applied would seriously hindered our development. Of two additional weeks on 
average. And that would be assuming that the schema is right from the first 
time. We were doing kind of that a long time ago when we had the DB freeze 
policy. Removing that was much appreciated.

So I think that if we want to reduce the delta that we build up between db-
devel and devel, we must investigate ways of applying DB patches without 
downtime. Or reducing the amount of downtime required for schema changes so 
that we can do it more often.


-- 
Francis J. Lacoste
francis.lacoste@xxxxxxxxxxxxx

On August 18, 2010, Robert Collins wrote:
> Right now we rollout two different production branches:
> stable to edge
> production-stable to everything else
> and production-stable is source from db-stable
> 
> (production stable is a private branch because if we have a CVE we
> need to apply we must embargo that per the CVE rules until its
> released).
> 
> To try and keep things consistent we merge
> stable->db-devel
> 
> automatically.
> 
> But, this means that there can be a bit of a disconnect at release
> time, so I'd like to propose that rather than having the branch with
> *db changes* -closer- to production
> (devel->stable->db-devel->db-stable->production), we should instead
> have it -further-away- (db-devel->devel->stable->production).
> 
> This won't work right now because we have lots of changes in db-devel
> and db-devel alone.
> 
> But! our shiny new workflow is nearly here. And when its here, we'll
> be rolling out stable to all the appservers, and eventually all the
> backends too.
> So, if something goes into db-devel, it should *only* be something
> that has to wait for downtime. There is no reason to put UI changes in
> db-devel, because they can come in a day after the downtime via the
> new process.
> So the only things that go into db-devel should be db patches that
> can't be deployed mid-cycle, and that means that its going to be a
> tiny delta, rather than the occasionally awesome one we get today.
> 
> Also cherrypicks will be just 'deploy stable' - the main thing will be
> agreeing to have downtime to do the CP (because things that don't need
> downtime we'll be deploying as a matter of course).
> 
> This might not be entirely focused as a concept yet :) Please poke at
> it to help me get the confusion gone.
> 
> In summary:
>  - When RFWTAD land
>  - DB patches *only* to db-devel
>  - db-devel merges to devel at the start of release week, once.
>  - devel merges to db-devel continually
>  - its DB patches *only* so no huge messy conflicts.
>  - We QA the resulting branch on daily-staging
>  - We deploy stable
> 
> -Rob
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~launchpad-dev
> Post to     : launchpad-dev@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~launchpad-dev
> More help   : https://help.launchpad.net/ListHelp

Attachment: signature.asc
Description: This is a digitally signed message part.