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 : [email protected] > Unsubscribe : https://launchpad.net/~launchpad-dev > More help : https://help.launchpad.net/ListHelp _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
