 Build, Release and Deployment Management is very much like designing the controls in the cockpit of a large airplane. Everyone understands the importance of creating complex airplane controls that are easy to understand and enable the pilot to make split second decisions with perfect accuracy. The field of ergonomics focuses on designing equipment, including complex controls that fit the operator perfectly, enabling continuous operation with few or no mistakes. We expect pilots to always understand their controls and never make mistakes that can endanger the lives of others. Read on if you would to apply these same techniques to Build, Release and Deployment Management.
Mistakes happen
Mistakes not only happen; but they can cost a lot of money as well. Human error, resulting in a major outage, can cause significant losses in terms of human effort, money and of course the unintended ramifications. Still mistakes happen and, in some cases, they can happen frequently. Serious the mistakes also result in exciting assignments for the CM professional. I have been down this path many times and entering a team that is making mistakes is an excellent opportunity to show how CM can positively impact the development effort along with the project and the organization as well. The secret is to know how to recognize the root causes of the error and pick the right intervention to see that future releases are completed perfectly each and every time.
Technology Professionals thrive being able to understand complexity
Why do most people enter the technology field? Obviously, technology is fun, but there is often another dynamic as well. Most technology professionals take great pride in their technical abilities and, in particular, their talents in understanding complexity. We love it when other people are impressed with how smart and talented we are. Solving impossible problems sometimes feels like putting notches in my technology "gunbelt". I particularly love tough problems because I know that I will solve them.
Many times, I have been in the position of having to learn someone else's existing (problematic) build and deploy system. I have also had to figure out how to fix whatever is broken. This experience always starts with the other colleague explaining to me, why this process is very complex and requires considerable effort. Secretly, I knew that this colleague would be delighted if I threw up my hands and simply declared that this particular build was too complex to be tamed. The truth is that I am not any smarter than my colleagues, but I do know how to solve these types of problems. Some of what I know is simply stealing good ideas from other people (and freely sharing them with others). I have also developed a methodology for examining and fixing the release management process.
Lifecycle of the release
The Release management lifecycle follows a natural lifecycle. Whether the project is using Waterfall or Agile, establishing a repeatable build process is essential for success. Too often this effort is anything but repeatable. One week the release will get done successfully and the next week it will require several tries because a step or two got missed. It is common for the release to fail and no one is really certain as to why. The first thing that the success CM expert establishes is a well defined and repeatable release management lifecycle.
Build engineering
Build engineering always starts with finding out what the developers are currently doing, Usually, their build process consists of pressing a function key from the developer's Integrated Development Environment (IDE). The developers usually do not know their own build dependencies (e.g. environment variables) which may be very complex. They often look for a build engineer to take over this chore. This effort becomes even more fun when the developer has to deal with new frameworks (e.g. hibernate), that have significant build and deployment requirements. The build engineer may need to work closely with the developers to automate the build using one of the common tools including Ant, Maven or Make. This is not a trivial effort and may require a significant development effort. The core requirement is that the build is automated and repeatable, and must result in a release that can be deployed to QA, Integration Test or Production without having to recompile (assuming Java) the Java classes and/or repackaging the jars, wars or ears for deployment.
Release Engineering
Release Engineering involves packaging the release and confirming that all of the components of the release (known as Configuration Items - Cis) are identifiable and fully traceable. Release engineering includes all of the supporting scripts to package, promote and trace the deployment of the release into QA or Production.
Deployment
Deployment consists of two steps. The first is to stage the release and the second step is to turn the release on. When Release and Deployment are done the right way - all of the work is done up front. Staging involves moving the release onto the target machines and completing all preparation for the release well before the release target date and time.
Don't forget the value of Backout!
Many people forget that the ability to backout a release is an essential competency. This is not a sign of weakness by any means. But the Release Management effort should include scripts and automation to quickly deploy and also quickly (and reliably) fall back to the previous release. Being able to quickly backout is essential to any release management process.
Rapid release management means rapid application development
The Rapid Application Development (RAD) process involves rapid code development, testing and promotion. When Release Management does a good job, then developers rely upon us to rapidly build and deploy. Another added value is that the developers can release smaller chunks of code and thereby reduce the risk. I have commonly found that we could take a three day (buggy) release process and bring it down to a one hour effort that is reliable and fully traceable.
It's the process
Establishing a repeatable process for build and release management truly demonstrates the value of good CM. Breaking each step down and making certain that mistakes cannot happen adds a tremendous amount of value to application and project lifecycle effort.
Trackback(0)
Comments 
Write comment
 |
CM Journal Articles 
TrackBack URI for this entry
Subscribe to this comment's feed