launchpad-dev team mailing list archive

[Tom Haddon <tom.haddon@xxxxxxxxxxxxx>]

On Tue, 2011-03-29 at 17:11 +1300, Robert Collins wrote:
> Some of you may have heard or seen me muttering about this, but I
> think that monthly releases no longer fit our model of development and
> deployment, so I want to change this - simplify and reduce it.
> 
> The 'release' process & cycle served many purposes for us:
>  - it avoided high risk events during Ubuntu release critical periods
>  - it signalled the exposure of new features to users
>  - gave a venue for events requiring downtime (such as security
> updates, hardware maintenance etc)
> 
> With the ReleaseFeaturesWhenTheyAreDone (continuous deployment)
> project all but done, the benefits we get are changed.
> 
> Now, the monthly cycle gives us:
>  - deploys of *QA'd* database changing code
>  - a window to do downtime maintenance on machines
> 
> As we wrap up the continuous deployment work we'll be able to do even
> more maintenance without downtime, further reducing the amount of work
> we do during the monthly cycle.
> 
> In particular, note that:
>  - we no longer have a qa rush: things that are QA ok when the time
> comes get deployed, things that aren't are carried over / rolled back
> (same as changes in devel) (Remember - our next db deploy is april 6th
> - if its not qa'd in db-stable by the 3rd april (monday oceania), it
> won't be carried into the release).
>  - we deploy only a small number of revisions on the downtime deploy
>  - we are stopping the practice of doing changes other than the db
> deploy during the downtime window (by making things changable without
> downtime)
>  - we don't 'release' anything during downtime deployments.
> 
> This leaves the following actions needed during the deploy cycle:
>  - far enough ahead of the deploy window for us to get through
> buildbot, and again if we choose to rollback, merge db-stable's
> highwater qa revision to devel.
>  - Discuss deploy windows with stakeholders and maintain the calendar
>  - liase with losas to let them know the revision of stable that we
> are deploying a few hours before the deploy.
> 
> So, I propose the following:
>  - Francis should do deployment window discussions.
>  - We make the 'please merge db-stable rev XXX to devel' a team
> responsibility, just like nodowntime deploys. I'll happily put the TA
> team up as a backstop for this - we'll make sure it happens.
>  - Likewise, we make informing the LOSA team of the revision to stage
> ready for the downtime deploy a team responsiiblity (again, with TA
> acting as a backstop to ensure it happens).
>  - We stop tagging bugs with milestones - we deploy only a few changes
> in each deploy, and we don't do feature releases at the same time. We
> also will be doing  *more* downtime deploys as we get faster DB
> deployments sorted out.
> 
> What-do-you-all-think?

I think my primary interest here is in what the practical implications
of this will be in terms of the number of "downtime/DB schema upgrade"
deployments there will be. Is what you're proposing going to mean more,
or less rollouts, and what's the predictability of those going to be?

Thanks, Tom

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