UrbanCode CEO and co-founder, Maciej Zawadzki, explains that Continuous Integration is more than just merging code. Join him as he explains some of the fundamentals of Continuous Integration in the third installment of the uChat video series.
We include a built in package repository, CodeStation, with AnthillPro, uBuild and uDeploy. They also integrate with third party repos. We place much emphasis on this capability because it is critical for safety, governance and audit.
To explain this, let’s first look at a simplified build and release lifecycle:
Developers submit their work to a source control system. A build is generated from that source and any dependency libraries retrieved by a tool like Maven or CodeStation. That build is submitted to test environments and certified. Finally, it is sent to production.
The following questions are important to be able to answer:
What is in production?
Was it certified in test environments (and by whom)?
How do you know your answers to #1 and #2 are true?
To be able to answer 1 and 2, you need an inventory of what version of something is in an environment or at least logging that indicates the version number. But to truly know that what is in production is what was tested, you have to ensure that not just are the file names the same, but that the exact same files were moved into each environment.
In order to know and prove that the files are the same, one must validate that they are bit-for-bit identical by comparing digital signatures or hashes at deployment time. It helps to actually have the original file around in a tamper resistant location. A good package repository, like the one in uDeploy, will provide that location, the automatic signature generation at build time, and the automatic verification so that you know that what is in production is exactly what was built from known source, and tested in the prior environments.
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.
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 →