Bob Aiello discusses hands-on software configuration management best practices within the context of organizational and group behavior.
Build and deployment are two of the most essential functions that are performed by the configuration management guru. In some ways, they represent the beginning and the end of the release management life cycle. It's important to understand all of the steps involved with creating an effective configuration and release management process. When done well, good CM adds value. I have personally seen situations where these practices saved the project and the actual organization itself. Read on if you have to develop an effective build and deployment solution complete with all of the other steps that are required as well.
The Six Pillars of CM
Configuration and release management includes a number of functions that support the complete development lifecycle of any project. CM is an essential competency for any organization and involves a number of critical functions. I usually organize these into the following list:
Effective build and deployment covers all of these functions, since in practice, there are many interdependencies. For example, you cannot build the release if you do not have effective version control over all of the source code and any other build dependencies (e.g. libraries). Change control helps to give visibility into the expected changes being delivered in the next release, as well as the essential controlled approval process to promote a release into production (or QA). Most build systems also handle creating the necessary config files to support interface dependencies including promotion from QA to production. Release management helps by packaging the CIs that can be easily deployed into production (or QA as needed).
Getting the Build right
Build engineering is one of the really challenging functions in the field of CM. Good build engineers add value by helping to create repeatable build procedures that are fast, reliable and traceable. I have had many times where I was able to shorten the build significantly by examining the reasons why the code took longer than expected to compile (and, in some cases, link). I have had builds that were less than perfect because of build anomalies that were often hard to find, and even harder to fix. The best build engineers work together with the developers (who are closest to the code) to find ways to improve the build process. In my career,
I have had times where we found that circular build dependencies and poorly understood build switches often needed to be adjusted in order to fix the build process. There are also times when certain parts of the build were repeated even when it was not necessary. For example, I recall a project where we were using C++ templates that rarely changed, but got repeatedly recompiled, adding hours to the build process. The solution ended up involving compiling the templates (once) and then checking the pre-built templates into the version control tool so that they did not have to be built over and over again. The discovery of the wrong compiler switches being selected led to further improvements in the build process.
The Challenge
The build process can have many challenges that might not be easily resolved. When this happens, the build engineer should facilitate having the best development resources help to analyze the current build procedures and recommend ways to improve the build. The build engineer makes the process reliable and repeatable, but is often not the person most familiar with the code.
I have seen builds that created the same binary with different sizes, much to the puzzlement of every member of the development team. Builds can be overly complex and not at all understood by the technology experts closest to the code. In this case, the build engineer needs to take the lead in getting the right resources to help troubleshoot the problem and then reach consensus on the best solution.
I have also seen builds that really needed to be broken into smaller, simpler builds (of individual components). Again, this must be done with the involvement of the development team.
Which tools should I use?
I have worked with builds using Makefiles, Ant, Maven (1&2), and MSBuild. All of these build platforms have advantages and disadvantages. It's usually best to involve the development team in the decision to adopt a particular build platform. It's even more important to set standards in terms of naming conventions as well as patterns using these tools. I have seen builds get completely out of control. The build engineer must work with the development team to set proper standards so that the builds are repeatable and efficient.
Embedding the Version ID
Any good build procedure is designed to embed an immutable version ID into the binaries created by the build. In CM terminology, we expect that every configuration item (CI) has an embedded (immutable) version ID.
Don't forget the code coverage
A good build procedure also automatically kicks off code coverage tools as well as unit test cases.
Build and Deployment
Designing the best build process will help to create a reliable and repeatable build and deployment process that will add value to your development team. Make sure that you include all of the members of the team to create the best results. Also, continue to join us at CM Crossroads, as we discuss all of the functions needed to create the CM processes!
