Posted on 5 August 2019, updated on 25 October 2023.

One of the main DevOps concepts is continuous integration. Continuous Integration (CI) is an essential component in an agile development environment. It includes a set of practices designed to accelerate the development of an application while guaranteeing the quality of the code.

The DevOps philosophy according to Padok

The DevOps philosophy is to accelerate developments. Padok even took inspiration from it when choosing his name. In Formula 1, the paddock is the area where the car is set up, adjusted, to be as efficient as possible and allow the driver to concentrate on what he knows: go as fast as possible.

In DevOps, the operational team (or Ops) is the equivalent of the top engineers who work on these paddocks. They work on the machines so developers (or Dev) no longer encounter any obstacles related to Ops issues (crashing servers, incorrect deployment pipeline, slow development environment, etc...) and can focus on the features to be coded.

What is continuous integration? How does it work in practice?

Continuous integration is a set of practices that consists of automatically testing each code revision before it is deployed in production. There is a difference between CI and CD (Continuous Deployment). Here is a diagram to visualize the process better:

continuous-integration-diagramCI consists of 4 steps:

  1. Plan
  2. Code
  3. Build
  4. Test

While the CD consists of:

  1. Release
  2. Deploy
  3. Operate
  4. Monitor

In other terms, when the developer codes a feature, he also designs the associated test and adds it to his code repository. After the code phase is the build phase. The CI tools will automatically go through all build steps (compilation, testing, packaging, etc.). If the CI tools detect a failure, the build is broken and displayed in red. The developer who codes it needs to fix it.

The integration server will then run all the tests to verify that no regression has been introduced in the source code. If a problem is identified, deployment does not take place and Devs are notified. If no errors are reported, the integration server can directly deploy the code in production.

Thus, with continuous integration, the automated testing phase is fully integrated into the deployment flow.


What does continuous integration bring?

The main contribution of continuous integration is to guarantee a quality code in production and therefore better satisfaction of end-users. Indeed, the tests automation of all the source code after each addition/modification of functionalities avoids the introduction of regressions in production. Developers can configure integration server notifications and be notified on the service of their choice in case of anomalies (webhook, email, etc...), saving valuable time.

In reality, not all the code is tested, because the development of tests takes time. At Padok, we consider that from 80% we guarantee good test coverage. It is better to have the main features tested than the whole application poorly tested.

Continuous integration also allows Devs to get faster feedback on their development. No need to wait several weeks anymore to identify and correct errors.

Finally, continuous integration encourages teamwork. Often, several Devs work on separate tasks within the same project. However, a large team involve a higher risk of introducing errors during integration. And in case of a problem, debugging can be very time-consuming. By integrating code revisions daily, the risk of error is minimized. Conflicts within the team are less frequent and Devs are no longer afraid to "break the code" with each deployment.

The tools of continuous integration

Different DevOps tools are available to manage continuous integration, here is a non-exhaustive list.



Jenkins is a free continuous integration software developed in Java. It runs in a web container or a stand-alone mode with its embedded web server. Being open-source, Jenkins brings together a large community that regularly proposes new service improvements. It is quite simple to install and more than 1000 plugins are available, allowing it to be integrated with most development, testing, and deployment tools.


Travis CI

Travis CI is a paid software for continuous integration, published under MIT license. It compiles, tests and deploys the source code of the developed software, in connection with the GitHub source code hosting service. It is configured in YAML. Travis also runs tests in Docker environments.


Gitlab CI

Gitlab CI is to Gitlab what Travis is to Github: an integrated end-to-end tool. Trainline testifies to his change from Jenkins to Gitlab CI in this article.



Bamboo is a continuous integration software developed by Atlassian. It is not free and its cost depends on the number of remote agents you need.



TeamCity is a continuous integration server based on the Java platform, developed by the JetBrains editor. It is accessible free of charge and thanks to a streamlined web interface, it is fairly easy to configure and use.

All these tools offer quite similar performances. To choose the most appropriate one, it is better to take into account the skills of your team by asking yourself "With which tools are my Devs most familiar?". The cost can also be used to differentiate these different tools.

Continuous integration as a first step towards continuous deployment?

Continuous integration is not a prerequisite for making DevOps, but rather an ideal to achieve, the first step towards continuous deployment. Automated tests constitute a quality wall, certainly not exhaustive, but which filters most regressions if it is well designed. Dev and Ops are thus more serene and able to deploy regularly.

Continuous Delivery and Continuous Deployment bring automation at a higher level. Continuous deployment is a practice of delivering each change to the software directly to end-users. No human intervention is necessary, everything is done automatically, unlike continuous delivery, which requires manual action for deployment. Only changes that fail a test are not directly deployed in production. This practice speeds up the feedback loop, and also allows devs to focus on developing the application since there is no longer a release date to anticipate.

To conclude:

  • Continuous integration is like a quality wall that the code must systematically pass through before being deployed in production.
  • This practice ensures quality code, satisfied end-users and more efficient developers.
  • Many tools, sometimes free of charge, allow its implementation.
  • Continuous integration is a good first step towards continuous deployment and continuous delivery.

If you have more specific questions, or if you would like to give us some information to complete this article, do not hesitate to contact us!