When it comes to builds, we often talk about build types - a development build, an integration build, a release build, etc. We very rarely hear people talking (or writing) about build promotions. We all agree that it makes sense to have stages for issues (defects). We know that an issue that is "open" means that work has not yet commenced on it; and an issue that is "in progress" is not yet ready to be tested, etc. We've also applied a similar concept of promotions to source code. But when it comes to builds, despite being used, the same practice has not made it into the mainstream vernacular (aside from a few hints here and there). This article is a small attempt to change that.

Simple Scenario

Lets start out with a very simple scenario that we'll use for this article. I always like to use concrete example as I think they make it much easier to communicate concepts that would otherwise seem complex.

For our scenario we will use a simple web based application (although it does not really matter what type of application it is). The important thing about our scenario is the lifecycle of the project. The first stage in the lifecycle is the development. After development comes the build stage. Automated functional testing is the next stage. And after that manual testing is performed. Once both forms of tests pass, we can go into production. This lifecycle is depicted in the figure above. A lot of the details have intentionally been omitted in this section as we will cover them in our two walk-throughs.

Walk Through using Build Promotions

In our first of two walk throughs we are going to use build promotions as the method for moving through the lifecycle. Essentially this will entail doing a build at the start of the lifecycle and then using those build artifacts at each subsequent stage of the lifecycle. The crucial distinction between this walk through and the one using build types is that in this walk through the artifacts produced by the original build are the same ones that are used at every subsequent stage of the lifecycle; whereas in the build types walk through a new set of artifacts is produced at each stage of the lifecycle. Lets take a quick look.

The lifecycle begins with a team of developers that is constantly making source code changes to implement new functionality as well as fix defects. At some point in time we can take a snapshot of the source code and perform a build. Determining the points in time at which we perform builds is beyond the scope of this article. Suffice it to say that such points do exist. Whether they be after every commit as in the practice of Continuous Integration or every weekday at midnight as we would do for nightly builds, or at other time(s) is irrelevant to our discussion.

Once developers have made changes and once we have chosen a point in time for the build, we invoke the build process. The build process takes the source code as input and transforms it into build artifacts (jar, war, ear, exe, dll, etc. files), which are the outputs. If we're invoking the build process through an Application Lifecycle Automation (ALA) server, the ALA server will create a build record representing our build process invocation. The build record will contain a bill of materials, other traceability and audit information, as well as references to the build artifacts.

Once the build has been performed, we can move to the next stage in our lifecycle: performing functional tests. In our walk through, once we get to this stage, we take the artifacts produced by the build (during the build stage of the lifecycle) and invoke the process that runs the suite of automated functional tests on those artifacts. We can also mark the build record as having been promoted to the "functional testing" stage of the lifecycle. Based on the results of the functional tests, we can make the decision of whether to continue promoting this build. For this article, lets assume that we will continue to promote this build.

The next stage in the lifecycle is the manual testing. Once we get to this stage, we take the artifacts produced by the build (during the build stage of the lifecycle) and hand them off to the manual testing team. We can also mark the build record as having been promoted to the "manual testing" stage of the lifecycle. Just like with the functional tests, we can make a decision on whether to continue promotion of this build based on the results of the manual testing. And just like before, we will assume for the sake of this article that we can continue.

The next stage is production and thus the artifacts will go through a deployment process that places the artifacts into production. Once we get to this stage, we take the artifacts produced by the build (during the build stage of the lifecycle) and invoke the deployment process, thus placing them into production. We can also mark the build record as having been promoted to the "production" stage of the lifecycle.

That's the entire walk through using build promotions. It should be pretty simple and hopefully is very intuitive and already what you're doing. The reason we went through it here is so that we can contrast it with the next walk through.

Walk Through

Using Build Types Lets now walk through the same scenario but using build types as the mechanism for moving from one lifecycle stage to the next. Using build types involves executing a different build type at each lifecycle stage. So we'll have a normal build type, a functional test build type, a manual test build type, and production build type. The thing about each of these build types is that each one of them starts out with the source code that has to be transformed into artifacts that can then be acted upon. Lets take a look.

Starting from the beginning, a team of developers is constantly making source code changes to implement new functionality as well as fix defects. At some point in time we take snapshot of the source code and perform a build, which takes the source code as input and transforms it into the build artifacts (jar, war, ear, exe, dll, etc. files), which are the outputs. We actually do the same thing in this walk though as we did in our last walk through. Thus far, both walk throughs are identical. The differences do not become apparent until the next stage.

After the build stage of the lifecycle, we move to the functional testing stage, where we have to invoke the "functional test build type," which performs another build from source thus producing a new set of artifacts. The functional test suite will then be run on those newly produced artifacts. Once the functional tests are complete, for the purposes of this article we assume that we will advance to the next stage in the lifecycle.

At the manual testing stage of the lifecycle, we invoke the "manual test build type," which performs another build from source thus producing a new set of artifacts which are then handed them off to the manual testing team. Once the manual test are complete, just like before, we are going to assume that we want to advance to the next lifecycle stage.

The next stage is production. The artifacts have to go through a deployment process that places the them into production. In this walk through, we invoke the "production build type," which performs another build from source thus producing a new set of artifacts. These new artifact are the ones that get deployed to production.

That's the end of this walk through. If you cringed as you read this walk through, then that was the intent. Perhaps we can start talking about build promotions as well as build types from now on.

The Lesson

OK, so perhaps our walk throughs are a little far fetched -- but that was done to make a point. There are times when using build types is appropriate, but not when it comes to managing the lifecycle of an application (as it goes from development to production). There, build promotions should be used instead.

You're probably left wondering why would anyone every use build types in situations like the above. The admittedly self-serving answer is that if all you have is a Build Management Server and you try to manage the lifecycle of your project using it, then you will essentially be forced to use build types. It's the age old problem of using the wrong tool for the job. The correct tool for the job would allow you to use build promotions.

Why Promote Builds and not Artifacts

By reading the above walk through, one could very well come to the conclusion that it is actually artifacts that get promoted rather than builds. While technically this would be the correct point of view, it is never-the-less beneficial to think of the entire build being promoted. Why is this so, you ask? Because builds carry with them a lot more information than artifacts. Artifacts, at best may carry with them a token that may be used to trace the artifacts back to the build that produced them. Builds, especially when performed on a build management server, are represented by build records, which carry with them lots of information including: traceability to the source code used; audit trail of who initiated the build, when, and with what parameters; and of course the artifacts that were produced by the build, among other things. It is only a natural these "builds" hold one more piece of data: the promotion level.

Conclusion

We've just scratched the surface of a large topic. This article is not meant to present a detailed and exhaustive model for build promotions. The ambitions of this article are much more humble: to merely get the practice on record, and perhaps to start a little thought and discussion about it. There are many questions that are left open for another day, including: implications on module builds and integration builds, implications of automating other processes in the lifecycle, and many more.

Add a comment

Posted by Maciej Zawadzki on February 20, 2007 10:08:00 PM EST #