Continuous Integration: What it is, Why it Matters, and Tools to Get Started
"Continuous Integration is a software development practice where members of a team integrate their work frequently [...]. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible." Martin Fowler on martinfowler.com
Let's bring the definition of Continuous Integration by Martin Fowler to a deeper level of understanding: Continuous Integration, a.k.a. CI, is a software development tool which is used at the integration stage of software development - as the name might suggest. "Integration," in this context, means sticking software pieces together like Legos to create a complex and working whole, resulting in a single product or process.
CI builds on using a version control system (like Git, for example), so to get started a “repository” is required. This is where changes to and versions of the software product are tracked (for more information, see the Wikipedia article on version control and/or this 10 min. video on YouTube: Git Tutorial Part 1: What is Version Control?).
What CI does is rebuild and test your “mothership” (in the form of the repository where your software product is located) each time a change or addition is made. It then gives you feedback: whether everything is just fine (build and tests succeeded) or if there are any bugs, which is usually the case ;) Hence, you'll get to know whether the pieces you just put together fit with one another and work as expected. This aspect in particular makes sense if you think about the fact that usually there are not only one, but at least a couple of software developers working on one project at the same time.
Now how about the "continuous" in CI? Well, once upon a time developers used to write big pieces of software that were integrated perhaps once a day (you might have heard of nightly or daily builds), or even more rarely. Now with CI you integrate your changes frequently and in very small steps: for example, every time a certain feature is completed or a new function has been added.
Developing software means that it eventually ends up somewhere, e.g. with a customer, in the app store, on the web, etc. Making software available to someone else (outside of the company) is commonly known as deployment.
Continuous Delivery means that we make the latest working and tested version of our software available to whomever it concerns, whenever requested. This is like making a copy of our mothership and pushing it to the production / deployment server, and within seconds the customer can take a look at the latest version of the software. In contrast, Continuous Deployment is the automation of the deployment process, hence no manual labor is needed anymore and the software is deployed as it is developed: in small, frequent steps.
So, it’s clear that CI is a helpful software development tool that you can't really avoid nowadays. But let's summarize the concrete advantages of using CI tools. The following points are extracted from and a (very) short version of Benefits of Continous Integration on martinfowler.com.
- Bugs: "Continuous Integrations doesn't get rid of bugs, but it does make them dramatically easier to find and remove." Hence, you'll work more efficiently.
- Overview: Historically, there's been a lot of uncertainty and unknowns in software projects. With CI you set yourself into to position to always know "where you are, what works, what doesn't, the outstanding bugs you have in your system."
- Breaking down barriers: "[continuous Integration] helps break down the barriers between customers and development - barriers which I believe are the biggest barriers to successful software development."
To summarize, the benefits of Continuous Integration are reduced risk, time, and cost. Apart from these benefits on a company level, there is also a personal benefit in for you: deployment in all its facettes is an exiting topic that is often feared. CI forces you to do so often, getting comfortable with it eventually.
While there is an upside, there is most certainly a downside, too. When considering Continuous Integration tools, what are the drawbacks that should be included in the equation?
- Maintenance overhead: The Continuous Integration server needs to be maintained and managed, just like every other server. This adds some overhead to your workload.
- Server dependency: If the CI server fails, well, everything fails. So a good amount of attention should be paid to server maintenance and security.
- Adoption: If you're working in a group or organization and try to adopt CI, it might take some time and effort to anchor it into your organizational culture. The most important thing is to get all the developers on board, and keep them there.
At INWT we currently use two different CI tools, namely Jenkins and Travis CI, depending on the project. These are both briefly introduced here. Of course there is a wide range of further tools that might fit your needs better - further down you’ll find a linked list with more CI tools (which of course does not claim to be complete).
Jenkins is currently the leading open source automation server, and is programmed in Java. It is distributed under the MIT license. Jenkins is absolutely free and very flexible, since it allows the use of a vast selection of version control systems, and offers more than 1,500 plugins.
Travis CI is also an open source automation server distributed under MIT, and is programmed in Ruby. Travis CI is free for open source projects and licensed for companies and private projects. Projects need to make use of GitHub as a version control system in order to use Travis CI as a Continuous Integration platform.
Our next blog article will focus on Jenkins, giving you a tour around and introducing the essential aspects of the User Interface. Once you’re familiar with this environment, you’ll have enough knowledge to start playing around with CI, and to do some hands-on exercises.