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 of impending changes. You may have to fight for preparation time early in a project, but specify it in a work breakdown structure or build it into your regular deployment process so that the team doesn’t feel ambushed when they are working against different deadlines than those you have in mind.
5. Understand the Impact
Well before software changes are deployed, clearly discern the impact on the existing system(s). You may have to adjust your expectations for release timing or the availability of people based on what subsystems are affected by the proposed changes. During a finite window at 3 A.M. is not the opportune time to discover that particular expertise or access is needed to complete the work. By the same token, understand what systems are reliant on the changes and ensure that relevant batch jobs or other activities are placed on hold if need be during the deployment work. A couple of things that often trip up a release are the preparation of hardware and the related network integration. Setting up URLs and getting site certificates are also common “gotchas”. They are most likely not your responsibility, but it never hurts to ask if the work is completed. I thoroughly recommend a pre-launch meeting with the team to go over each step of a release to make sure that everything is covered and everyone knows the times and personnel involved in each activity.
6. Get the Right People Involved
Make sure that the people who will (or may) be needed to successfully deploy the software are scheduled and prepared. They will need to know the appropriate timing, as well as the location or conference numbers and access codes. Know who is required to be on site and who can simply be “accessible”. You may have a project manager to chase these details down for a major release, but if you’re doing a regular deployment, odds are you will have to do it yourself. Where possible, create calendar entries in the email system so it’s easily visible to the others and actively reminds them.
7. Communicate the Release
Communication is important before, during, and after the release. In some organizations, the communication is split internally and externally so that a business representative will be the conduit of information to the client. Team members should know in advance what’s happening and be kept aware of progress during the release process. Clients, managers, and team members may all require different forms of correspondence in terms of content and formality. Distributions lists created in advance can be extremely handy to avoid leaving someone off of an email at a critical moment.
8. Execute Efficiently
Time is quite frequently at a premium during a software release. For both significant projects and maintenance work, the order of work should be delineated in advance and structured to improve quality and reduce the expenditure of time. Most releases are not done single-handedly, but involve numerous individuals from across the organization, each with a dollar cost associated to the work. Per hour costs can run easily run into the thousands depending on the complexity of the release.
9. Verification and Validation
As the objects are deployed, a team should be verifying successful implementation of the code itself. This might take the form of running sp_help on databases or running server audits to ensure the right material was migrated successfully. Post deployment testing by the QA group, client or business, or both should validate that the code is operating as intended. Just as before release, the test teams will face pressure to complete the work quickly. Don’t hesitate to step in to give them the support they need to do the job right. Clients are much more forgiving about handling things within the deployment window than having discovered them on their own later on.
Conclusion
Release Management is more than just the physical code insertion. It requires a high degree of preparation and coordination to execute efficiently and accurately. Particularly if you have well defined and limited windows for the release, Fortune certainly favors the prepared. And while these dicta may be less critical in testing environments, the core principles remain the same. The stronger the repeatable process is, the better your end deliverables will be, which reflects not only on you but the entire organization. Boelcke was the most successful pilot of his day not just because he was a multiple Ace, but because he could communicate his process to the other members of his squadron and thereby improve everyone’s performance.
Randy Wagner is a Contributing Editor for CM Crossroads and Senior Configuration Manager with EFD in Sunrise, FL. His experience ranges from major financial institutions to multimedia multinationals to the Federal government. Working in small to large project efforts has given him a unique perspective on balancing the discipline of SCM and enterprise change management with the resources and willpower each organization brings to the table. You can reach Randy by email at [email protected]
