Release management best practices have evolved over time as software tools that manage and automate parts of the process appear. As a result, established structures are ever changing. An example of this is a 2007 piece on Buildmeister about best practices that were inspired by ITIL, the ISO standard IT Infrastructure Library.
The biggest observation I have about the 2007-era best practices suggestions are the barriers erected between the development and the operations team regarding software deployment, configuration, and testing. A modern DevOps culture, where everyone on the team uses a common source code control system, is missing, and it's replaced by admonitions to keep the teams separate for management and accountability reasons.
What else has changed in the intervening six years? The 2007 view of best practices doesn't touch on virtual machine configuration management, which is critical to the world of the modern data center.
An admonition to use "a Deployment Management tool … to move the release to different environments or to install onto multiple desktop machines" needs now to accommodate quickly building and spinning up virtual machines for operating and test environments.
Surprisingly enough, many of the rest of the suggestions still make sense. It's still all too true that "Software Release Management can be a repetitive and error prone manual process, therefore as much as possible should be automated." Buildmeister has good recommendations about software packaging and the need to put together testable releases. There's a curious lack of emphasis on an automated test and build environments, perhaps reflecting the relative immaturity of those tools six years ago.
Time and change march on, and if you are using a state of the art systems approach from the previous decade, there may well be ways to improve the software release management process. Look for ways to get from the previous generation of best practices to the current generation.
No comments:
Post a Comment