launchpad-dev team mailing list archive

[Robert Collins <robert.collins@xxxxxxxxxxxxx>]

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