In theory, build management is simple. But like many aspects of IT, in reality, it's quite complex. This article introduces the basics of build management and provides a foundation on which to build further study.
Build management should be very straightforward and to the point, but like most IT subjects, it is far from simple. To start off, build management is not the act of performing a build. That is simply building code from source files. The automating, scheduling, and accuracy of those builds is where the “management” side comes in. I will be covering the basics of build management in this article, nothing complex, just the basics.
Have a Good Build Process First
Before you do anything associated with a build, you should have a good process mapped out as to the who, what, when, where, and how the build will be completed. Who is responsible for the build and the contact person for errors? What is actually being built and its dependencies, i.e., a configuration items list of what is expected and included in the build? When are the builds to be done? Where are the builds going to be deployed? How many different builds are we going to do? Once these factors are known, the process should be documented thoroughly and then you can begin the steps of automating your build procedure. Having a good process before automation will result in fewer headaches down the road. Automation of bad processes only hastens the impending doom that will result.
Automate your Builds
This should go without saying. Anything that can be automated should result in less time to complete and reduce the number of errors that can occur. Build errors are costly in terms of lost labor hours and to your customers if they go undetected during the testing process. Simply automating the build is not enough, the automated process should also give you detailed log files about what has happened during the build and also when and where in the build any errors occurred. This brings up an interesting point; folks who normally do the builds manually sometimes fear that by automating the build they will no longer be needed. On the contrary, automation simply shifts the focus of how the build is completed; there will still be plenty of work to do keeping the automation and build scripts up to date and working. Very few automated actions are static, change is constant and builds are no exception to this rule.
Build Manually
This is actually a part of build automation. How? you may ask. While build automation is very important and necessary, so is being able to do the build manually. Someone actually told me that, “Before a build is automated there should be a good manual process for the build available.” Why is this important? What if something breaks in your automated build? What if the people who wrote the build scripts left your company? What if there is a change in a operating system, a patch or upgrade that breaks the automated build process? Part of build management is to be prepared for these types of failures, and it could take days to fix the automated build or even figure out what went wrong. This could result in testing, deployment, and release delays and that is never a good thing. Someone needs to know how to manually build all of the applications that you are responsible for.
Continuous Integration
This can be defined as “The practice of frequently integrating one's new or changed code with the existing code repository.” The theory behind this is that as code is checked in, errors can be detected earlier in the process rather than later. This will help keep the cost of finding bugs down. Detecting bugs in production can be extremely costly and can be devastating to a company’s bottom line. So the concept is this: a developer checks in his code and is picked up in the next build, as the builds are running continually. Depending on your environment, this can be twenty-four hours a day if you have multiple development sites, or eight hours in a smaller shop. This forces developers to test their code earlier and fix bugs before they get to user acceptance or production. It creates a mentality of "My code has to work before I check it in." This, in theory, will cut down on rejects and code fixes before they get too far downstream.
Who Is Responsible for the Builds?
Historically, this has fallen on the CM person. This topic of whether CM is responsible for builds or not is often debated. I am not here to debate the validity of CM doing builds, but only to say who shouldn’t perform the builds automated or manual. One concept that has come out of software development lifecycle models and standards is the concept of segregation of duties or separation of duties. This is paramount in build management. I say this with no reservation, people who develop code should never, ever, under any circumstance build code that is going to UAT or production. This is not a question of trust or not, I believe most developers would do the right things; however, safeguards must be put in place that limit the risk that code could be changed without it being checked in, which could result in damage to the environment and harmful to the customers. This also applies to the build manager. Under no circumstances should he allow code to be built that has not been put in the build repository, period. With those two statements said, if there is a production issue, this rule can be relaxed. However, after a production issue is fixed, the code change that was made should go back through the normal process as soon as possible to make sure other areas weren’t broken by the change.
Conclusion
Build management is concerned with timing, content, scheduling, and consistency of the many types of builds possible. This includes baselining the code that is included in the builds that go to testing. Making sure that all builds are timely and deployable is extremely important. In addition, build management is the first part of the greater deployment process, which is make or break for some companies. Get this part wrong and your company can spend a lot of money chasing errors and issues when it should be deploying and releasing code. While I have only scratched the surface of builds—and at times this field is not that glorious and at the forefront of release fanfare—that does not reduce the importance of building and managing your code repository. On the contrary, it is one of the most important steps that validates the development and starts the release process in motion.
