What Is Continuous Integration?
As the name implies, continuous integration (CI) is the software development practice in which developers make small changes to the code (adding a capability or function) and the testers immediately test those changes within the entire set of software to make sure the change works as planned and that no previously developed coding was broken in the change. The process has four basic steps. They are:
- Team members check in code they have developed into an automated source code management system
- A build server (Source Code Management System) monitors the repository
- Code is checked out by the SCM
- A new build, with the newly developed code, is continuously compiled and tested for bugs
While CI is all but unimaginable to a team steeped in a Software Development Life Cycle (SDLC) culture it is sometimes scary even to a team operating in an Agile environment as well. Updating code practically from minute to minute? That's insane. At least so it seems. While there are some aspects of SDLC processes that can benefit from Continuous Integration, the natural place for CI is within the Agile environments.
Requirements for Success
Continuous integration demands a single source repository. The repository must be the only location for storing and retrieving (checking in and checking out) files. This can be done by implementing a competent Source Code Management (SCM) tool. While it should be an integral part of any project, it is essential for Continuous Integration activities.
The project members must know where the project code is stored and how to store and retrieve the coding. This is a matter of training, making people aware of the processes involved in code development and maintenance. Part of that training is the absolute requirement that a single copy of any code or file be stored in a single location. Management must ensure all code is stored in the SCM.
And by "all code" we mean ALL CODE, including the actual system code, test scripts, database schema, install scripts, and libraries and executables. They should all be grouped as a part of a release, maintained by the SCM.
We have discussed Agile philosophy and various Agile software development processes in other articles. But we should note that for the most part, the process even within the "standard" methods of Agile development is usually the development of user stories, the creation of code to implement the user story and the testing of the complete coding once the coding has been integrated. All of this is completed within the confines of a Sprint, and are completed in sequence over a period of two to three weeks.
Unit and Integrated Testing
As stated earlier, a unique aspect of continuous integration is the frequency of testing. Rather than waiting until a large amount of coding has been developed and added to the existing system, small changes are tested using a copy of the production server.
Unlike development in a scrum approach, in continuous integration the code is tested repeatedly, in some cases multiple times a day. Once a piece of code has been developed, the developers check the code into the library. If configured properly, the SCM monitors the library and when a new piece of code has been delivered, the code is tested; first to make sure the new code works and second to make sure nothing was broken by the addition.
Automated testing is a requirement for efficient continuous integration. Within this context, the primary goal is to verify that the additional code hasn’t broken the original system. Regression testing is the primary objective at this point, automated regression testing.
If the code is passed by the build server, development continues. If the code fails, efforts to correct the bug take priority to development. Once the bug is repaired, development continues. This is something of a variation of Test Driven Development (TDD) in that test failures drive the direction of the code development.
Build and Deployment
As with testing, building a release within the Continuous Integration environment is best automated. Generally, getting a set of files turned into a running system requires compilation, moving files around, installing schema for a database, and a lot of other things. This can be done manually, but to do so, repeatedly, sometimes several times a day, wastes time and invites error on the part of the developers. Automation allows you to run the same installation script each time, the same way. The only variable, or critical activity, is making sure the pieces of the release are where they are supposed to be. And since the only files available are the most current files, there need be no concern about file versions or content.
A second characteristic of an effective build tool is that it can analyze what needs to be changed. This will usually be done by the tool's examination of the of the files' change date.
There have been several studies on the efficiency of continuous integration. Most of them revolve around several factors.
The process guarantees compiling will be successful for a release. Each change is tested against a "clone" of the operational software.
The development team is able to identify the bugs and create high quality changes to address those bugs as soon as they are discovered. If testing is done every day or more frequently, bugs can be identified and repaired every day, before a significant portion of coding has been developed.
CI also makes it easier to hold the developers accountable since the process makes it easier to identify who created the defective code to begin with. Accountability consistently creates ownership. And ownership encourages the creation of quality code.
If implemented correctly, the use of continuous integration can drive down the overall cost of system development. Less time is spent identifying bugs, correcting bugs, and retesting bugs. If an automated build server is used, much less time is spent creating a build for testing and for release to production. And since a large majority of the bugs are found and addressed prior to the production release, there will be far fewer trouble tickets to address.
In order for continuous integration to work, several criteria have to be in play.
- The client must be comfortable with continuous integration. Some clients may not find constant updates to their systems acceptable.
- Some industry environments are not suitable for continuous integration. The medical field and aviation require extensive testing in order to incorporate code in an overall system.
- The environment used for compiling and testing must be identical to the production platform.
- The approach requires strict discipline on the part of the participants. Failures in following the processes will invariably generate errors, costing time and money.
- It is generally an all or nothing operation. Continuous integration's efficiencies and benefits depend on, at a minimum, the above four criteria.