In his Behaviorally Speaking series, Bob Aiello discusses hands-on software configuration management best practices within the context of organizational and group behavior. While conventional wisdom may say that "change comes from the top," Bob Aiello explains that change often needs to come from the bottom, that is the people doing the day-to-day work.
Configuration management experts must always contend with evaluating and determining the best strategy to improve CM best practices. Most process improvement gurus sing a mantra that always seems to begin with “change comes from the top,” but the truth is that change often needs to come from the bottom—that is, the people doing the day-to-day work. I usually get brought into an organization when things are very bad. I often hear that the builds are broken and mistakes are made during the release-and-deploy process. My job is to figure out how to fix the problems. You may find that you need to address similar challenges to successfully implement CM in your own work.
Starting from the beginning usually means that you need to write a software CM plan. I was privileged to serve on the team that updated the IEEE 828 Configuration Management Standard, which provides detailed guidance on how to implement configuration management throughout the entire lifecycle. I would love to say that I always start with a plan, but that would be less than truthful. Usually, I start by observing the existing operations and making my best guess as to why mistakes are being made and other root causes that impact quality and productivity. This usually takes me straight to the procedures that handle application build, package, and deployment. Source code management is also one of the key areas to consider up front because it provides the means for reliably building and packaging the release. For example, code baselines are necessary if you want to be able to have a repeatable build, package, and deploy. Developers need the right tools in order to be effective.
Too often, I find that developers cannot work with the existing source-code-management tools. Sometimes this is simply because of a lack of training, and other times it is because the tools in place are a poor choice for the team and organization because they don't provide the functionality required to support the software development process. In these situations, I often find that developers not only are failing to safeguard their code in a version control system but also do not know how to baseline their code when creating a release that is intended for QA testing or even production. Without effective source-code management, including baselining, you cannot even start implementing application build, package, and deploy.
The key to improving your team's build-engineering practice is for you to understand not only its existing procedures but the problems that it is running into as well. In my line of work, sometimes the technology itself challenges me. Many technology professionals specialize in one platform, but build engineers are usually working across all of the platforms in use at the firm. This means that on a typical Monday, I am handling build, package, and deploy on a Linux server, and by Tuesday, I am knee deep into C# and .NET. As tough as this sounds, you really do need to understand the architecture of the system in order to create an effective strategy to handle the application build, package, and deployment. This is precisely why some build engineers are embedded with the developers so that they can fully understand the application and successfully automate every aspect of the application build. Knowing the application is key, but so is automating every step of the process.
Scripting and automating every step of the process, a practice I routinely do, can be very challenging because the procedures and the application build itself may be in a state where changes are occurring on a regular basis.
There are two more considerations that I always find essential for automating the application build. The first is that I do not try to write perfect scripts in the very beginning. Having a script that automates most of the build and then prompts me to review the screen and press enter is less than elegant but is a very practical approach.The second consideration is how to test my procedures up front.
If you ask a developer how to test the build process, you will often get a blank stare and maybe even an explicit complaint because some developers find it difficult to specify testing criteria. But, when things go wrong, the developers always know what to look for to diagnose and fix the problem. You should capture these steps and make them your own test procedures.
I found this especially useful in taming the maven build in one organization.
I worked as a build engineer in a group where the maven build was ridiculously over complicated. A smart guy with a PhD (sadly not in computer science) had written it. Every step of the process was more complicated than it had to be, and there were often challenges. Every time something went wrong, the developers checked to see if a particular java archive (jar) file had been created. I modified my scripts to always check for the missing jar early in the build stream. Although this didn't completely fix the process, it mitigated the risk because I knew right away if the jar was missing and could just rerun the build to fix the problem. This is a great example of where I needed to focus on the details of the build process in order to bring about positive change.
Most process improvement enthusiasts will focus on the importance of working from the top down, including a strong focus on getting support from senior management. It is certainly true that buy-in from senior management is essential, but you also need to consider the risks, such as making decisions, involved with trying to improve your process without all of the essential technical knowledge needed to tackle and complete the task. The most effective approach is to work from the top down and also from the bottom up.
