I find a lot of excitement in being boring. Really!
But I suppose I should say something about the context of that…
I’ve been spending a lot of time over the last couple years focused on the build/deploy cycle in a nearly-Agile environment (still working on the Agile part). I’ve been involved in deployments before but for the first time I’m in an organization that really wants to do it well, and is willing to invest in doing so.
We have certain goals:
- Have productive development and testing environments
- Have boring deployments into each environment, including production
And here are the characteristics of boring deployments:
- Little impact to the end users
- Minimal downtime
- No errors introduced by the deployment process
- Up-to-date help documents, customer service preparation, training infrastructure, etc.
- Not a fire drill
- Few people needed to run the deployment process
- Minimal time spent gearing up for deployment
- Quick deployment time
- Low risk of having to call anyone else during deployment (or afterward) to deal with issues
- WYSIWYP (What You See Is What You Planned)
- Expected features are present and working
- Bugs (well, most of them) known
- Managers come to expect few problems related to deployment (unfortunate side-effect: they then forget its importance and difficulty)
- Developers, including Quality Assurance staff if the organization has such positions, expect the software to work as well in production as is did in all the test environments
- People take vacations without having them interrupted or preempted by deployment issues.
As you can see, I think that the software deployment process should involve the whole organization, not just IT Developers and/or IT Administrators. I’m (mostly) a technical guy and expect to write more on what this means to developers and administrators. But I think it’s good to put it in proper organizational perspective.
And it’s good to be boring!