I was recently brought into a conversation about continuous integration and build management. The questions were predictable: What’s the difference? Are they the same thing? They’re both kinda about build, right?

The two efforts are quite different. However, in practice, the steps taken to achieve them overlap significantly.

Build Management Build management controls what goes into a build, creating a bill of materials, and then tracks that build from creation to go-live.

Continuous Integration: Is a practice of developers committing frequently to a common code line which is supported by aggressively testing the resulting software to verify that it’s getting better, not worse. Maciej Zawadzki expands on the quality emphasis of continuous integration here.

Diverging Goals , Similar Automation

We have these two ideas which on paper have almost nothing to do with one another. Then we look at how you might accomplish each with automation. For build management, you would have rules that would determine your source and dependency inputs. Automation would execute the formal build process and store the output files (artifacts) somewhere safe and traceable. For continuous integration, you would also have rules for defining what to build, then run the build, and some tests. If CI is extended to functional testing, you would need to manage the built files so that they can be deployed somewhere for testing. That’s a lot of overlap.

What happened is that early CI tools and early automated build management tools had such similar feature sets that the market identified them as competitors. Competitive pressure helped merge the feature sets so that most CI tools today (and any tool that effectively does continuous delivery), also provide build management to one degree or another.

For more on the difference between build management and continuous integration, see our white-paper Drawing the Line: Continuous Integration and Build Management