In September, 1916, Oswald Boelcke published a set of principles for air combat that, if followed, gave a pilot the framework with which to be successful. Dicta Boelcke is still taught to pilots today because the precepts have endured the test of time. In this article, I will endeavor to provide an analogous structure for release management, beyond just the code and particularly suited for those working with “live” environments. These are principles I’ve learned through painful experience or through the patience of those more knowledgeable.
1. Don’t Break Production
The highest priority is to ensure system viability. There are always well-intentioned pressures to rush in something that may not be ready but could bring down a running system. Be certain that the deployment follows the Hippocratic Oath to do no harm. Demand to see the signoff from the quality assurance group, or ask for approval from a senior manager. Even if you are dead set against something you may be overruled and that’s an organization’s prerogative. There will also be times when known flaws will be introduced after due consideration by the change control board but, as a general rule, existing functionality should not be compromised.
2. Define the Deliverables
While it’s often the very last thing to be known, the content is the core of release management. Pressures from clients, management, and project obstacles often make it difficult to nail down what the final deliverables will be until the last possible moment. Hopefully, your change control board or project team will have determined the content of the release in advance, rather than it being stitched and pinned like a wrong-sized bridesmaid’s dress. More than simply knowing which code revisions are expected, a good release manager must know if those are the tested and approved versions. You may also need to be aware of which code variants are being released simultaneously, and to whom.
Last minute changes should follow some form of exception protocol, allowing management to govern the increased risks associated. Also, include any non-code deliverables like a version description document, required audits, or other communication from the project group and management.
3. Use the Tools
If you’ve done your configuration management well or you have a better class tool to work with, it will be easy to associate the right code with the specific change requests included in the release. Use version labels or promotion levels to clearly delineate associated objects. If there is a repeatable release task, it can probably be automated to save time and improve accuracy. Investing a day in scripting may save several hours per release on an ongoing basis. Some configuration management tools allow you to spot code dependencies more readily than others. Make sure those dependencies are resolved before the release. The issue tracking tool should allow you to identify any outstanding issues and see that they have been appropriately dispositioned. Post deployment, you may have (or be able to create) tools that verify that the objects have been successfully deployed to all expected servers.
4. Identify Timing
Your team should know well in advance what the release timing will be. That’s not just the actual deployment date and time. The team should be aware of the timing of each critical node in your release process, such as the preliminary builds, final change control board meeting and other approvals, deadlines so that system administrators have time to adequately prepare for the deployment, final reviews of code or deployment packages, creation of appropriate documentation, and any other event specific to your organization. You (or a business representative) may also need to ensure that affected clients are aware