Behaviorally Speaking Behaviorally Speaking: Build Management- A Critical Milestone in the Release Management Process!
|
I always talk about “Process” in all of the classes that I teach about Software Configuration and Release Management tools and best practices. After I have used the word a few times I always stop and ask everyone in the room to define a process. Most people answer by saying that it is a checklist. They often neglect to mention defining roles, responsibilities or even milestones to test or Quality Assure the build and release process. It turns out that Build Management is a key milestone in any release management process. It is also often an “Achilles Heal” for many development teams. Whenever I am involved with auditing a development team they usually cannot pass the independent build test. There are several common problems and pitfalls that can easily be avoided. Read on if you would like to create Release Management procedures that include effective Build Management and “smoke” tests to support your SDLC. Human Factors for Developers Right after I graduated Hofstra University with my Computer Science degree I became fascinated by the work done by Frederick Winslow Taylor (Scientific Management). Taylor looked closely at exactly how workers did their job in an effort to improve productivity and avoid mistakes. Much of Software Process Improvement discipline is really about the same thing. Taylor did time and motion studies. We need to look more closely at how CM Practitioners make mistakes that lead to costly rework or even worse promote a release to production that can’t be properly identified and supported by Production Support. I have developed a series of rules that I jokingly call the “Bob-isms”. These are best practices that I have learned over the years avoid mistakes and allow us to get it right each and every time we create a release. The Integration Team A few years ago I was asked to review the Release Process employed by a large Corporate Integration Team. My job was to help the team figure out why they had suddenly started making costly mistakes. I joined the team as a “Participant Observer” which meant that they all knew why I was there, but at the same time I was a member of the team and doing actual work. The first application that I promoted took me about 10 days to understand and write some scripts to automate the build, packaging and promotion. The manager gave some feedback to my boss that I seemed to be a little slow in coming up to speed. When the 2nd and 3rd releases were completed in less than an hour each, he called back to completely retract his complaint. They just weren’t used to putting in some extra time up front to make the process a little more automated and “fool” proof. Here is what I did to make the process error free. Don’t Over Automate… Writing scripts to automate the build process is obviously a great idea. But there is also a danger that this can become overly burdensome and that is exactly why some people fail to automate their build process. When I download some code from many websites I can count on being able to use the Makefile in a consistent and reliable manner. This is an ideal that is great when you can manage it. The Nightly Build Lots of Unix C++ developers do a great job of automating the entire build process so that it can be built each night automatically. If this is your world then you are a lucky professional. My world is often more challenging. One thing that I always require is trace-ability. My automated build procedures always send me email to let me know that they have run and to make it easy to track down a listing for any given day. Nightly builds are great, but they can also be expensive in terms of resources (e.g. disk space). Evaluate whether or not your environment really needs a nightly build before you spend the time creating it. One thing that I have found useful is to create separate CM repositories for source and object code. I don’t backup the object code that is built during a Nightly Build unless it is part of a Production (meaning tested) release. Attended Automation I work in distributed systems where a major release may have software on Unix, Windows and Mainframe that all need to be coordinated for each release. Changes to databases may involve DBA modifications that are release specific. When I write some integration and release automation scripts I often don’t try to be perfect. Some of the scripts simply remind me to check certain required steps or look for expected error messages. I call this “attended automation”. I can’t make a mistake because my scripts (and maybe a checklist) remind me of everything that I need to do. But I often stop short of trying to make the automation completely perfect. On one job, my manager used to follow my instructions and create the releases even though he had very little technical background. I was delighted that the build process was clean enough for him to be able to cut the releases, but I also stopped short of trying to make it completely automated. Potential for Error One reason that I promote this approach is that it is often very hard to predict changes that may brake an automatic build. I like to focus instead on making the process easy to follow and (almost) impossible to mess up. I like to focus on the Human factors when considering how people make mistakes and what we need to do to prevent them. The Dangers of “Smart” IDEs Some integrated development environments can create serious obstacles for creating automated builds. There is a tendency to trust the IDE to make the right choices. The problem is that many developers don’t know the required environment variables (e.g. classpath). Some dependencies may be maintained in registry settings that can be tricky to uncover. You will discover them when your machine crashes and you try to build the application on a new machine. I recommend trying the build from different machines, ideally a new machine that just has the IDE itself installed. I often find that it is enough to ask a developer to let me build his code. It usually takes three tries before I find out all of the secret tweaks that were necessary to build the release on a different machine. I have found it useful to run the IDE from the command line so that I can write a script (e.g. bat file) to automate the build process. What’s That Got to do With CM? CM practitioners are in the business of helping developers to safeguard their source code. It turns out that all build and runtime dependencies (including the build scripts themselves!) are just as important in supporting a release and helping an organization to utilize CM best practices. When my colleagues need to fix an application quickly I want them to be certain that they get to the source code, build and release it efficiently. Milestones Checking code into a source code repository is not sufficient to comply with my CM Audits. I require that developers also demonstrate that we pull the code out based upon some baseline controls (in ClearCase we used LOCKED version labels). Remember that the last step in any build process is running Automated test scripts to perform a “smoke” test. The important Milestone is that the release can be rebuilt without (as my boss is fond of saying) “heroic” efforts. Considering the Human factors will help you create release management procedures that are complete and error free. Please drop me a line and share your best Build Management tips!
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.
Set as favorite
Bookmark
Email this
Hits: 9101 Trackback(0)Comments (0)
|
| Last Updated on Tuesday, 01 April 2008 11:00 |
TrackBack URI for this entry
Subscribe to this comment's feed