The Release management process is often an overlooked step in the Software Development LifeCycle. Usually, this “drudgery” is delegated to the most junior member of the team. With little or no background the release manager can make mistakes that can cost the team a great deal of time and effort. Putting out bad releases can ultimately cost the company a great deal of money and seriously impact the bottom line. How can we most effectively define the release management function to demonstrate it’s value and develop a process that works for the company, the development team and the individual assigned this important responsibility?
Why I Love Being the Release Manager…
The best reason to love this job is that the release manager is often the only member of the team to understand the big picture. Developers typically understand their part of the system well. But dealing with a production problem can often seem like a game of “techie” volleyball. I have seen developers spend hours trying to prove that a problem was really in someone else’s code. The release manager builds all of the components and usually gets to assemble (e.g. integrate) them as well. There is gray line into the testing area. Make sure that you erase that line thoroughly. The release manager should absolutely get involved with running the “smoke” tests to see if the newly deployed release meets basic functionality. I have always made it a point to learn all of the technologies that I work with at some level (yeah I buy a lot of books!).
As a release manager I get to see new technologies much faster than most of my colleagues. I see what everybody is doing. I do spend the time skimming the code so that I have a basic idea of how the system works. I always pick one or two pieces to learn well. But the exposure to many technologies helps me to stay technologically flexible.
Defining the Roles…
It is important to define the roles and responsibilities of the developer vs. release manager position. For one thing I always insist that there be traceability to confirm what the developer is giving in a particular release. I have actually heard people try to suggest that the release manager label the code instead of the developer. This is an example of a very bad practice that will lead to the developer blaming the release manager for grabbing the wrong versions. Defining the roles and responsibility is key to avoiding human error.
In a very large team, there is always one developer who integrates the code, gets a good compile and then promotes the code to testing. We call this person the integration developer.
Confirming the Build…
For the release manager, the integration developer turns over the code via a well defined (traceable) process. We use version labels. The Buildmeister owns the label, so he controls the locking mechanism. I always ask the integration developer to label EVERYTHING in his view. It is common for there to be compile dependencies that have been long forgotten. If the developer might have included the file, then it should be labeled. From a process point of view, the Buildmeister rebuilds everything and puts the newly built system (including source code) into the Release repository. It may sound like a few extra steps, but in the end, this is an ideal process. Notice also that the roles and responsibilities must be clearly defined. One way to really make this work, is to rotate the buildmeister and integration jobs among the developers. This means that you are guaranteed that the process is repeatable and everyone will cooperate because next month it will be their turn! For a detailed discussion of defining the release process, please see my July article.
The release manager (sometimes called the Buildmeister) has the job of confirming the build. In my company this means that the developer checks his code into a repository and the Buildmeister pulls it out based upon a version label. The code is then completely rebuilt from scratch. The newly built release is the version that is deployed to the test team and eventually production. This is an important step that confirms that the developer has indeed checked in and documented all of the build dependencies.
Rapid Application Development…
Some release managers complain that they get too many releases. We look at this differently. Providing a fast and effective way to build and deploy a release provides the development team with lots of added value. Defects are best addressed in short “spiral” lifecycles. A reliable efficient release management process makes this possible.
Including the Testing …
We launch “smoke tests” immediately after a nightly build. This gives us a moderate amount of testing immediately after the build is complete. We also use many low-level test drivers. These test drivers require a fair amount of expertise to build and run. This is where the buildmeister can often work effectively as a tester, using his/her expertise of the system and it’s overall architecture.
Managing for quality …
In Industrial psychology, we often look for ways of avoiding human. Human Factors has become it’s own discipline. Winslow Taylor started by looking at how workers use a shovel. The Release Management process must be designed to avoid and guard against mistakes. If the Release can be created, without mistakes, at 2 AM (meaning when everyone is a little sleepy) then it is a repeatable, reliable process. When we design process and script automation we try to think about the common ways in which people make mistakes. Through a combination of good documentation and automation, we design our release procedures so that they can be run by any technology professional without making mistakes.
Flexibility …
Flexibility is the most important trait of any good technology professional today. The technology changes rapidly and we all need to adapt to a constantly changing world. The Release manager often has some especially important skills that helps to make the project and the team successful.
Bob Aiello is a Senior Contributing Editor for Crossroads News and an Associate Director at Bear Stearns & Co. where he is engaged in Software Process Improvement on a large scale basis. He is also on the Board of Directors for the Organizational Development Network of Greater New York (ODNofGNY) and a member of the Steering Committee of CitySPIN in New York. Mr. Aiello has a Masters in Industrial Psychology and a BS in Computer Science.
You can reach Mr. Aiello by email at raiello@acm.org
Trackback(0)
Comments 
Write comment
 |
Behaviorally Speaking 
TrackBack URI for this entry
Subscribe to this comment's feed
