Continuous Integration: What Is It and How Can You Achieve It?

Continuous Integration (CI) is a process in which changes from a code’s repository should be synchronized as often as possible. Team members should share changes among each other after every finished and checked fragment of the task implementation or each finished task (it depends on the size and complexity of tasks).

Advantages of Continuous Integration

One of them is the shortened feedback loop for the team members informing about the code quality in the repository. Thanks to that, potential problems could be found earlier and fixed quicker. With the fresh head, so to speak, when people responsible for the destabilization still remember what exactly has been changed. It also lowers the risk of implementing additional changes, they should be checked for quality after all. At last, the CI process should speed up communication between the developer’s team members; they should synchronize their work with the main code branch as often as possible. That way updates made by other team members should not be that surprising.

How to achieve Continuous Integration

The team should make a roadmap known and accepted by all. It’s important to have only one code repository that will be shared among all software product developers, same goes for the continuous integration server (also known as a machine for dirty work). Team members should synchronize their changes as often as possible, however, synchronization or implementing changes into the repository should be preceded by checking if the code is generating and if all tests are successfully passed (you should always establish a minimum number of tests that a team member should perform before committing changes). Solidity is important so that the code in the main branch would be stable and working. If the continuous integration server finds problems, not even one change in the code should be made, you should wait for the repair of the source. Even the smallest committed changes while the code is not building can significantly complicate bug tracking or the analysis of strange application’s behaviour.

The next important element is time. The application should be small enough for the code generation time to check if everything is ok. Therefore you should keep the generation time as short as possible. It also affects tests that should be run before every committed change into the repository.

Tests that are the foundation of CI should be quick and automatic so that people responsible for them should not spend more time on testing than necessary. We are talking about unit tests as well as UI, integration or end-to-end tests. Tests on the CI server should be performed in the environment closest to the natural productive environment as possible.

The practical side of Continuous Integration

We need a Continuous Integration server. Its tasks will be to download current sources, their building, test running and informing the team about the results. Sounds easy enough but it isn’t. In reality, everything takes time so the important thing is for the building and tests to be as quick as possible. In theory, all changes should be tested with a complete test package. In practice it can be impossible for the big projects and you’ll have to compromise. You have to establish which tests are most important for you, which can be put aside for a moment, which can give us the most reliable information about the source quality with the shortest time needed for results. There is not a good solution here and every team should run the appropriate analysis on its own. Tests that are not performed with regular intervals should be put aside but performed as quickly as possible. A daily, overnight build should help here; it will perform all available tests.

Email notifications for all team members should also prove valuable. The good practice is also to monitor the status of sources; displaying statistical data on a dedicated monitor is also a good idea.

As a server for Continuous Integration, we can use one of many existing platforms like Jenkins, TeamCity or Visual Studio Team Service. They will help with the overall quality of the code and let you sleep at night. Especially with an overnight build.