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