Tuesday, August 28, 2007

Release Management and QA

I spend a lot of time working in small companies. "Release manager" is one of those roles that typically isn't filled by an actual person. Instead, it's a combination of a developer, someone in IT, and usually QA. So when you walk in and they say, "well, QA helps out with releases", what should you look out for?
  1. Let's talk configuration. Manual changes are bad, because they're error prone. The fewer manual configuration changes you have to make, the better. I'll do a full post on this one later - configuration is difficult.
  2. Release night. Yup, you may need to be there. By the time it gets to releases, you should just be there to do a smoke test. QA really shouldn't do the release; whoever runs your production environment should do the release.
  3. Documentation. During releases is not the time to rely on people's memory. Whatever your release process, whether it's "cap deploy" or "run installer X" or "drop file set Y in location Z" should be meticulously documented.

The biggest thing to watch for is the Go/No Go decision. This is not your decision. It's tempting to get sucked into this, and it's very common to hear "well, is it ready?". But this is not your call. Your purpose is to provide information, but the decision needs to be made by the product manager (or appropriate substitute).

And that's it! Your particular situation may have other considerations, but really these are the basics

No comments:

Post a Comment