Tom is in the final stages of implementing the qastaging server. The appservers are up already, its just librarian and so on that are remaining.
it will auto update as frequently as we can make it; for now (IIRC) that is hourly - and there shouldn't be (much) downtime when it updates. Once this is live we can execute on the next stage of release-features-when-they-are-done, which is: "In progress - Stage 2 - QA all code" To execute this the following production changes will happen: - edge autodeploys will be turned off - cherrypicking will be disabled - we'll start deploying from the deployment report - as often as revisions are in good shape on that report (yes, multiple times a day is fine (*)) - deployments will go to *both* edge and lpnet, always - production-devel and production-stable will go away What do we need to do as developers? - QA as rapidly as possible (and as thoroughly : the outcome of the qastaging step is 'ok to deploy'). Use qa-bad and bad-revision=12345 tags to mark revisions that *must not* be deployed. - If a revision is bad fixing it is a stop-the-line event : no other deployments will happen until its fixed. Use revert liberally - its the fastest way to restore to a known good state. ref: https://dev.launchpad.net/MergeWorkflow and https://dev.launchpad.net/QAProcessContinuousRollouts (*) There is a small amount of downtime deploying to appservers at the moment, and will be until RT 41503 (no downtime upgrades of appservers [hack]) is done. Francis, you might like to increase the priority of that ticket - it should be 89 I think. Cheers, 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
