launchpad-dev team mailing list archive

[Maris Fogels <maris.fogels@xxxxxxxxxxxxx>]

On 11/01/2010 06:58 PM, Robert Collins wrote:
> Now that we're doing RFWTAD, I'd like to change our release process.
> 
> From:
> lock down devel landings (to release-critical)
> lock down db-devel landings (to release-critical)
> while unqaed: qa
> choose the rev of db-devel
> unlock things
> @scheduled time: release
> merge db-devel to devel
> 
> To:
> merge db-devel to devel
> lock down devel landings (to release-critical)
> while unqaed: qa
> choose the rev of devel
> unlock things
> @scheduled time: release
> 
> This will have the following impact:
>  - we'll see a clean db upgrade happen with all the db patches
>  - code will converge faster (because we don't wait for the release to
> have db-devel merged to devel)
>  - revnos in production will not jump around
> 

Very nice.  This could make the rollout process much faster and less stressful.

I noticed one point missing from this summary: the use of a full weekend staging
update to gauge the rollout downtime, and presumably to forecast the clean
application of all DB patches from the last week.  This update also has the
unfortunate potential to block all QA for patches landed after Monday.

I do not see the database update steps mentioned in your summary.  Are they
something we should think about?  Can we work them into, or out of, a shorter
release process?

To better visualize what happens today, here is a rough release timeline:

Thursday:
  lock down devel landings (to release-critical)
  lock down db-devel landings (to release-critical)
  while unqaed: qa
Saturday:
  * wait for a full staging update
  * work to get the staging database to update cleanly
Monday:
  rc-landings
  while unqaed: qa release-critical work
Wednesday:
  choose the rev of db-devel
...


Maris

-- 
Māris Fogels -- https://launchpad.net/~mars
Launchpad.net -- cross-project collaboration and hosting

Attachment: signature.asc
Description: OpenPGP digital signature