When we look at software builds, we’re looking, for the most part, at dependency problems. Traditional build scripting tools like Make or Ant are dependency languages. In order to do thing A, do B and C first, etc, etc.
The example below, in order to build the very small program “unique” main.o and strset.o need to be built. Those in turn rely on the input files main.c, strset.h and strset.c.
Understanding this graph is important for performing an incremental build. Continue reading
The cultural aspects of continuous integration are something we’ve covered on this blog before. But today, we’d like to highlight a recent entry from James Bettely’s DevOps Ramblings that asks, “How Mature is your Continuous Integration?” James focuses almost entirely on the cultural aspects and nails it in the conclusion:
The hardest part to get right, particularly in distributed teams or in companies over a certain size, is the culture. You have to have a team of build engineers and developers who all understand the big picture. Developers need to understand that they are instrumental in making the system work – their input is vital, and they have to understand clearly what benefits they will personally get from this system, otherwise they’ll ignore it. Build engineers in turn need to understand that the more you are able to devolve the ownership of the system, the better it can work, and the more buy-in you will get in return. The build system needs guardians, but it doesn’t need treating like a holy relic.
These cultural aspects are a great compliment to our enterprise CI / CD maturity model. Download that white paper.
Our team is excited about the release of 3.8 (the last major release under the “AnthillPro” brand). There are lots of great new features and a special emphasis on easier maintainance and management in environments with hundreds or thousands of projects or servers.
Personally, I am particularly excited about using jobs multiple times in a workflow and easier inter-project dependency configuration. For more on the new features, check out the 3.8.0 release page.
Also available (for 3.7+) are new or updated plugins for IBM’s Rational Team Concert & ClearCase, Amazon EC2, VMWare vCenter Lab Manager, Bullseye, Microsoft IIS, Websphere, Fitness, Selenium, and TestNG.
While I can not take the credit for coming up with Continuous Integration (it can be traced back to timeless practices) or for even coining the term, I can take the credit for creating one of the first Open Source (later turned commercial) CI servers — Anthill, released in July of 2001. That has given me an almost unique vantage point for watching the evolution of CI and seeing it take the industry by storm. One of the most interesting phenomenon I have come across was seeing our customers use AnthillPro (back when it had build only functionality) to automate deployments back in 2004. Keep in mind that this was back in the days before the term Continuous Delivery was coined. At first it seemed to me that the wrong tool was being used for the job. But then I realized that the features present in any implementation of CI really advanced Automation from the invention stage to the innovation stage. Continue reading
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
Vast majority of daily practitioners of Continuous Integration don’t really understand it. This is a bold statement, I know. But it is not made to simply capture attention. Most practitioners of Continuous Integration, when asked, will either tell you that CI is about integrating changes often, or that it’s about producing frequent builds of your software. Both these answers are incomplete at best. Even articles on Continuous Integration gloss over the thinking behind it and jump straight to the implementation.
So this blog entry is about the “thinking” behind Continuous Integration. Because only by understanding the core ideas behind CI can you understand what is happening in the industry now or get a glimpse of where it is headed in the future. Once you “get” the core concepts behind CI, it’s easy to see that Continuous Delivery is a natural extension of Continuous Integration. Continue reading