Implementing the tools and processes necessary to support build and release management is an important task that can make the difference between success or failure for your development effort. Build management can be your greatest asset or the source of many problems that could ultimately cost your team a lot of time and effort – along with the risk of increased defects resulting in poor quality. This article lays out the first things that you need to consider in order to win with build management essentials.

Source Code Management
If your code is safeguarded in a reliable version control or source code management solution (and they are not the same) then it will be much easier to create repeatable builds based upon a persistent baseline of the code (representing a significant milestone). Version control tools give you basic checkout/check features with the ability to tag or label your code representing a specific point in time when you have a milestone release. Source code management raises the bar by promoting workflow automation and support from a wider Application Lifecycle Management (ALM) perspective.

The difference is significant in that using workflow automation helps to organize your entire team's work by providing support for workitems (e.g. tasks, defects) that can be tied to changesets - committed to complete a specific set of changes. Robust ALM solutions raise the bar by integrating with requirements tracking, test case automation, incident tracking and even project management solutions so that you can be certain that you have full test coverage and you did not accidentally miss an important requirement. They also make creating robust release notes much easier as well. You need to start your build process by making certain that all configuration items are safely secured and identified in a source code management solution. The next step is to make certain that you have good build procedures in place.

Version Identification
It is very important to be able to identify all configuration items (e.g. binary, library, config file, document) using a unique and immutable version ID. Code that is running in production must be capable of easily providing an identifier so that you know the exact version at any time. For example, the “About” box in your favorite desktop application will usually show you the unique version often along with the build number and the libraries that were required for the build. I have written many other articles on how to embed Version IDs in Configuration Items using Java/C++ with Ant, Maven and Make. Drop me a note and I will send you the links! Once you have version identification (which is a key part of the classic CM function called configuration identification) you will be able to setup automated configuration audits which is an essential compliance requirement. This allows you to verify that you have the right code running in Production (UAT or QA as well).

Fast Builds
I have spent a lot of time creatively engineering builds to be fast and completely automated. This is a task that does require some effort, but it is also critical to your success. Sometimes, it means lobbying for a well provisioned build server and setting up your environment so that you can kick off a pre-QA build – even from your laptop on the network. Getting your build fast and reliable is absolutely essential. This is indeed where cloud computing can be very helpful in allowing you to request a temporary Virtual Machine (VM) that can be used for rapid build, package and deploy (possibly to another VM that is your test box). Builds should be part of a comprehensive deployment framework.

Deployment Frameworks
Just building your code is not enough. You also want to be able to implement a fully automated release and deployment framework. This allows you to arrange your builds into a logical structure with each piece functioning as an independent component. The framework gives you visibility into which steps have completed and notification if any failed. More importantly, you can then scale the deployment to as many machines as necessary. Build and deploy is essential but you also want to have your code defect free. Let's discuss how to do that.

Code Analysis and Testing
Building your code is just the start. You also need to be able to run static code analysis as well as instrumenting the code for multiple variants as needed. In this case you would be building a version of code that allows for instrumentation to support dynamic code coverage or even performance testing. The build is also the right place to automate both unit and runtime regression testing. One of the best ways to implement these features is through continuous integration.

Continuous Integration
Whether you are doing Agile or Iterative Waterfall, continuous integration (CI) is a best practice that you will want to implement. In the classic sense you have the CI server “wake-up” when code is committed and automatically build the entire release from scratch. There are many popular CI servers and they have a number of robust features including scaling to large distributed teams. Whatever your requirements you will want to make use of a CI server even if you only want to setup a nightly build. Modern CI servers provide a great framework for getting this done easily and provide a console so that you know who broke the build and what needs to be done to fix it (by showing the exact changes that caused the problem)

Conclusion
Implementing build management is essential for your team's success and these are just a few of the essential practices that you need to implement to get this job done effectively. I hope that you will drop me a line and let me know about your own build management best practices and what you have found to be essential!

Trackback(0)

TrackBack URI for this entry

Comments (4)

Subscribe to this comment's feed

Bob Aiello said:

	... the only way that I know of to stop the volleyball is to move CM upstream. That means that I make all of my build automation available to developers as an unofficial "service". If you do that - the devs will never break your build again because THEY will depend upon it. Bob
	report abuse vote down vote up

April 29, 2011
Votes: +1

Muhammad Saqib Khan said:

	... Thank you very much Bob again for your prompt reply. Sure, I will watch your presentations shortly on youtube. Actually it is almost a 'volleyball' in my case too and am quite anxious to correct such problems. Thanks!
	report abuse vote down vote up

April 29, 2011
Votes: +0

Bob Aiello said:

... it depends a lot on the industry that you are in and whether or not there are any regulatory requirements. In defense, you would likely have a planned build with many mandated controls (try being a build engineer for the FAA :-) I usually ask for a pre-release build from the devs using the same build machines that I will be using. This is very easy to do if you have an automated deployment framework (plug here for a few of my favorite vendors). Otherwise you get into "volleyball" where devs hit the ball over the net to SCM and they it back over the net when the build fails. Finger pointing and lots of wasted time are next. This is precisely the issue that devops is trying to address. You can look for my youtube channel called cmbestpractices where I have a four part presentation on a related topic.

report abuse vote down vote up

April 29, 2011
Votes: +0

Muhammad Saqib Khan said:

... Bob: I agree with your all mentioned view points and I learn a lot from it. I would like your opinion that if the builds from development side is not planned or they have not perform unit or integration testing before sending to CM engineer for build generation than the risk of getting error during build generation is quite high, thus all effort, time & cost during configuring and compiling a build for a CM guy waste. I want your opinion in this scenario that whether it can be the lack of process implementation, poor project management or how we can overcome such problems. Our main target is to resolve build generation problems or errors before freezing the code. Also is it necessary that builds should be planned? What would be the approach of modular base builds where only 1-2 files are changed at a time and CM guy has to build incremental Exe's in such case? Please share your experience. Thanks!

report abuse vote down vote up

April 29, 2011
Votes: +0

Write comment