What is Continuous Integration and Why Do We Need It?

Continuous Integration is a set of software engineering practices that speed up the delivery of software by decreasing integration times.

Sounds good but what are these practices?
Although these practices existed before, extreme programming practitioners recommend that teams require their developers to continuously integrate. I will give more detail about the practices later on, for now here is the list:
· Maintain a code repository
· Automate the build
· Make your build self-testing
· Everyone commits every day
· Every commit (to mainline) should be built
· Keep the build fast
· The build needs to be fast, so that if there is a problem with integration, it is quickly identified.
· Test in a clone of the production environment
· Make it easy to get the latest deliverables
· Everyone can see the results of the latest build
· Automate Deployment

Maintain a code repository
I think everyone is on board with the concept of a code repository. It provides versioning of the source code add allows management to see who did what when through comments placed in the revision log each time code is checked in. Consider for a moment, how many times code has been checked in, only to later cause someone else to download code that wont compile? How much time was spent trying to figure out what the problem was and resolve it?

Automate the build
Enter the automated build, this means that the entire system should be buildable using a single command. This is in contrast to a manual build process where a person has to perform multiple, often tedious and error prone tasks. The goal of this automation is to create a one-step process for turning source code into a working system. This is done to save time and to reduce errors.

Each time the system is built the code is compiled, if for any reason the build fails (including syntax errors or missing resources) everything stops. This code should not be accepted into the repository.

Make your build self-testing
The system should be written with tests that verify that it performs as intended. These tests should be run as part of the build. The best way to make the build self-testing is to create “unit tests” for each granular function within the business layer. At build time each of these unit tests could be run to ensure that previously written functionality still works and is compatible with the latest updates. To get the most from unit testing a strict barrier between the UI, business, and data layer should be implemented.

The value of a self testing build grows exponentially as your application gets older and more complex.


Everyone commits every day
By committing regularly, every committer can reduce the number of conflicting changes. Checking in week’s worth of work runs the risk of conflicting with other features and can be very difficult to solve. Early, small conflicts in an area of the system cause team members to communicate about the change they are making.

Every commit (to mainline) should be built
Commits to the current working version should be built to verify they have been integrated correctly. A common practice is to use Automated Continuous Integration. For many, continuous integration is synonymous with using Automated Continuous Integration where a continuous integration server or daemon monitors the version control system for changes, then automatically runs the build process.

Keep the build fast
The build process needs to be fast, this way if a problem with integration is identified, it is quickly identified and addressed by the appropriate team members.

Test in a clone of the production environment
Having a test environment can lead to failures in tested systems when they are deployed to the production environment, because the production environment may differ from the test environment in a significant way.

Everyone can see the results of the latest build
It should be easy to find out whether the build is broken and who made the change. This provides a valuable “state of the application” while at the same time providing a measure of accountability.

Automate Deployment
Automated deployment removes the human factor or “Magic” from deployment, as the system always follows the same procedures and therefore is less error prone.