launchpad-dev team mailing list archive

[Danilo Šegan <danilo@xxxxxxxxxxxxx>]

Hi Steve,

I wanted to clarify a few things.

У чет, 23. 07 2009. у 11:13 +1000, Steve McInerney пише:

> We appear in this thread to be confusing two related but quite separate
> issues.
> 1. is releasing a bunch of code at a given version
> 
> 2. is updating a highly complex, live production system across multiple
> servers: Coordinating h/w upgrades; kernel patches; database
> upgrades/patches; managing users' expectations, and fitting in with
> their schedules; minimising outages etc etc etc... and - oh yes - using
> the latest version of the aforementioned code :-)

Not all of the above (2) is part of RM role.  We are still going to fill
in separate positions of a Technical Lead and a Project Manager (to also
carry out coordination between what seem to be IS/OSA jobs you describe
above, and our development team).  RM is not going to replace Francis or
Kiko (some would say they are irreplaceable ;), but is going to
alleviate them from some of the tasks that we want other people in the
team to try their hands at, and that we trust to do so.

> Basically it boils down to:
> Does the Release Manager wear the responsibility - and corresponding
> authority - to stop a roll-out to the production system, because, for
> example, some branches aren't tested.

In short, yes.  We want release managers to be flexible with all this
though, and to make sure that we do not come into a situation where
there are any landings which are not tested.  It's their job to ensure
that no 'NEEDSTESTING' item remains on the TestPlan for each of the
applications.

So, we believe that with a well defined position of a release manager,
we can get into a situation where we roll out higher quality releases
simply because we have an eager person doing the job of tracking down
every little detail of the rollout and taking responsibility for it.

Authority is what a prospective RM should have, and what they would get
in return for taking responsibility for the release.

> Will they also accept the ultimate blame - buck stops here - for
> failures in the release?

Of course they will, if it happened due to them failing to fulfill any
of the duties they were supposed to do.  There are many things RMs do
not have power of that they can't be held responsible for.

They would be in charge of ensuring that prior to the rollout:

 * Launchpad code base is in a good working order (stable, db-stable in
good state, no problems with PQM or similar)
 * Suitable QA has been carried out
 * No blockers for the rollout have been registered or they have been
resolved
 * Everyone who participates in the rollout procedure is well aware of
the timing, procedure and the steps they need to carry out
(announcements, what's new updates, last minute fixes, dependency
installation, rollout itself)
 * Nobody critically dependent on Launchpad availability will be
affected by the rollout (i.e. important customers would talk to them
about the rollout timing)

If they can make sure all of the above holds, they've done a good job.

> If not, then why not?

This means that in the first few runs, we should be a bit more flexibile
as we define the position in more detail and document exactly what is
essential for carrying out a successful release.  The wikipages we have
seen are definitely a good start, but without going through an actual
release or two and writing everything down, I'd never claim them to be
complete.

Also, we are not a group of head choppers for the first mistake.  Taking
responsibility means taking blame as well, but overall, entire team is
to be held responsible for a bad rollout.  If someone qualifies as a
really bad RM, the team reserves the right to not let them do it again.
And that's where the bucket can stop.

> Release Manager is not just a pretty hat to wear, it's a real
> responsibility with serious consequences associated with getting it
> wrong.
> 
> .... and no rewards for getting it right. ;-)

It seems as if you are describing OSA jobs as well :)

Cheers,
Danilo