Did you forget your: Username / Password ?

Microsoft

TechWell

Home

Behaviorally Speaking

Behaviorally Speaking: Automating the Software Build and Release Management Process...

Written by Bob Aiello

Friday, 02 January 2004 16:00

Automating the Software Build and Release Management Process is a dangerous task that can lead to disastrous results!! I have known software development professionals who have insisted on doing every single step of the Build and Release Management effort manually. These professionals would tell me that automating such complicated tasks was virtually impossible and could easily result in a bad release. I have learned (the hard way!) that the effort to automate every step of the Build and Release Management process is sometimes just not worth the time. This is particularly evident in large development (e.g. Global) efforts where the BuildMeister can get surprised with significant new changes in each major (and a few minor!) release. There is a point though where automation does add value by saving time and improving Quality. Read on if you’d like to share some thoughts on what can and should (and what should not!) be automated in the Software Build and Release Management process!

Excuses or Legitimate Reasons?

This is a painful issue. Sometimes developers refuse to automate their procedures because they are afraid of letting go of the tasks that led to their success. Some people want the job security of being an essential (and indispensable) resource. Why automate when it may cause me to loose my job? Other developers will argue that automating their procedures is just too difficult and not worth the effort. When does it make sense to automate?

Goals for Effective Automation

You should automate your Software Build and Release Management process to:
-Avoid missing a step (or make some other mistake) that can lead to a bad release. Bulletproofing the Build and Release Management process add value by improving quality and avoiding costly mistakes. Automate so that you can the Release right each and every time!

- Provide a foolproof process that can be accurately performed at 2am (or any other time when you might not be able to fully concentrate. I love creating a release when the process is so tight that I can enjoy going through the mistakes knowing that I cannot make a mistake!

-Audit trails consisting of full logging and tracing of each step is extremely helpful when things go wrong and you have to figure out what happened! My beeper goes off when certain errors are found and email routinely goes into folders, sorted by rules, making the debugging process easy. Yeah I get a lot of email, but I purge it after a while and it is very convenient.

-Error and event handling can be handled when the process is automated. This can something as simple as moving a symbolic link to point to production, ONLY if the build process succeeds. Not only do we have good traceability, but a lot of events can be handled automatically.

-Confirmation of a Successful process is a lot better than assuming a job completed successfully unless you get a notification. I like the warm feeling of being proactive and knowing that the Build Process was successful.

- Anyone can do the release. I remember when I wanted a day off and my (non-technical) boss followed my (written) directions and created the release himself. It definitely helped him to understand my job better and appreciate what I do. I didn’t have to play hero by putting off my personal life.

- Ultimately, the build process can often be completely automatic and foolproof. This is an ideal that is often not worth realizing. There is a practical point in which there is just enough automation to accomplish our business goals.

Getting it Done…

Flexibility is essential in this task (and lots of others too!). I always start by simply making sure that it is impossible to leave a step out of the Build and Release Management process. The checklists and scripts step me through the entire process and make it impossible for me to accidentally skip a step. The logging facility helps to confirm that I did each step in the correct order. It’s easy to get distracted and completely forget where you were in a 15 step release management process!

Be flexible – Think out of the Box!

We assume that the Buildmeister might be running each step of the process from the command line or as part of a long stream. Each script is autonomous or confirms that it’s dependant libraries are available. It is essential that the script prompt the user for missing information and log all inputs and choices. This is both a valuable training tool as well as an essential way to confirm that everything was done properly.

If you Were Sitting Next to me…

If you joined me in creating a release, you would see each step generating a log message and then a comment reminding me of what I expect to see! For example, my script might print check for the existence of a config file or dependant script. The message will say “Look for script xyz” and then the script will pause so that I can confirm everything is exactly as it should be. When I am confident that the script can be part of a larger automated stream then I simply remove the pause statements and the script can run as complete batch job. In Unix, it is common to use the “tail –f” to confirm that all of the running messages are exactly as they should be.

Keep it Simple

I try not to make these efforts any more complicated than they have to be. I am trying to take the anxiety (and potential for errors) out of the Release process. If a simple pause and quick look will get the job done, I don’t need a complicated message parser to automatically analyze each message. Most of all the effort to automate the process should be simple and easy to understand (and improve!). We all have a lot to do. This is definitely one instance where the most value can come from very basic and minimal work!!

Bob Aiello is a Senior Editor for Crossroads News and an Associate Director at a major financial services firm in NYC, where he has company wide responsibility for Software Configuration and Release Management best practices. Bob is on the Steering Committee of the NYC Software Process Improvement Network (CitySPIN), where he is also the chair of the CM SIG which meets in Midtown NYC. Mr. Aiello has a Masters in Industrial Psychology from NYU and a BS in Computer Science from Hofstra.and Release Management best practices. Bob is on the Steering Committee of the NYC Software Process Improvement Network (CitySPIN), where he is also the chair of the CM SIG which meets in Midtown NYC. Mr. Aiello has a Masters in Industrial Psychology from NYU and a BS in Computer Science from Hofstra.

You can reach Mr. Aiello by email at raiello@acm.org

Set as favorite

Bookmark

Email this