Introduction

I am sure most software developers have heard of Continuous Integration (CI). Some may use it, and a few may even have set up and configured such an environment. For those who are not familiar with it, or need to justify why their development team should introduce it, then I hope this tip provides some solid justification.

CI is very often implemented in conjunction with Agile, Test-Driven-Development (TDD) and automated testing. If your development team adopts any of these processes and / or methodologies, then CI is a natural fit thus making the decision even easier, and reducing the pain points involved.

Background

I have been an ardent proponent of Continuous Integration for several years now. Having set up and configured CI environments from scratch, and seen firsthand the many benefits to be achieved from adding CI to your development process, then the decision to introduce it really is a trivial one. The question is not so much "why should I add CI to my development process?" but "why shouldn't I introduce CI to my development process?".

This tip is not intended to go into any details about a particular CI tool or technology or to give instructions on setting up and configuring a CI server, but is instead intended to rationalise why a development team should consider spending the time and effort of implementing CI. After all, there is no such thing as a free lunch, and it takes time and effort to introduce CI. You need to select an appropriate tool that fits your existing technology ecosystem, and then you need to set up and configure it for use within your current development environment. All of this takes time and effort that could be utilized elsewhere. So the goal to this post is to give justification as to why adding CI to your development process is worth expending that time and effort.

What is Continuous Integration?

Here is the definition of CI from ThoughtWorks.

Continuous Integration (CI) is a development practice that requires developers to integrate code into a shared repository several times a day. Each check-in is then verified by an automated build, allowing teams to detect problems early.

The basic idea of CI is to build and integrate the software frequently. This can be as frequent as every code check-in. Batched integration is also common whereby the software may be integrated when a series of code check-ins have happened, such as when a feature is complete.

As a bare minimum, a CI server will build and compile the software, and integrate this with any other software articles into a deployment. Additionally, it is common to execute unit tests as part of the CI process. This further ensures that the newly checked-in code has not inadvertently negatively impacted the codebase. I'm sure we have all experienced the situation where we have tested our code, only to subsequently find out that it has in fact broken a seemingly unrelated part of the software.

Benefits of Continuous Integration

If you're going to fail, then fail early - One of the driving forces behind CI is to detect problems with the software as early as possible. If you only build and integrate your software prior to testing, then you are increasing the risk of the software failing by not building it with sufficient frequency. As your development team continues to add new features to the code and fix bugs, the codebase is constantly in a state of flux. If you are not employing a CI server to continually build your software, then you have no idea as to the health of your software. Remember, any change to software (even one that fixes a bug) can cause destabilisation. If you are not aware of this destabilisation, then you cannot fix it. CI flags these sorts of problems early in the development cycle, where they are easier (and cheaper) to fix.
Separate software builds from software deployments - There is no need to couple these two processes together. With a CI server, you are easily able to completely decouple these two processes from each other. Whereas previously your build process was more than likely also responsible for deploying your software, with a CI server, this need no longer be the case. A build and a deployment within the context of a CI server are isolated and independent activities with no intrinsic dependency upon each other. You may have your CI server configured such that every check-in made by a developer triggers integration, but the deployment of that build may be a manually triggered process by a member of the testing team.
Enables Continuous Deployments - Continuous Deployment is closely related to Continuous Integration and refers to the release of software into a live (production) environment that has successfully run any unit tests associated with the build process. In its most simple form, Continuous Deployment is the practice of releasing every good build (into either a UAT or production environment). By adopting Continuous Deployment together with Continuous Integration, you are actively reducing risks by detecting bugs and finding build problems early, and therefore more easily able to move rapidly towards working software.
Enables automated testing - If you currently employ automated testing or are looking to employ automated testing, then CI should be considered an enabling technology. As stated already, in addition to building and integrating the software, any CI server is also able to execute unit tests. The benefits of doing this should be self explanatory. However, by running unit tests against the codebase on a frequent basis provides rapid notification as to any breakages in the code, particularly those in unchanged areas of the code. It is not so much the successful builds that are important, but the unsuccessful ones.
Increases confidence in the software - By continually building the software and (optionally) executing unit tests, increases confidence that the software is of high quality. That's not to say that the software meets the needs of the business (that's a whole different discussion), but that as an absolute minimum it is of sufficient quality that it could be pushed into a UAT environment (or even a live environment).

Summary

This tip has hopefully provided justification for introducing Continuous Integration into your development process. There are many different tools to choose from so if you haven't already added Continuous Integration to your process, then there is no better time than the present. Feel free to leave a comment if you would like me to further elaborate on anything within this tip.