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.