The DevOps philosophy is to accelerate developments. Padok even took inspiration from it when choosing his name. In Formula 1, the paddock is where the car is set up and 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.
Continuous integration is a set of practices that automatically tests each code revision before it is deployed in production environment. There is a difference between CI and CD (Continuous Deployment). Here is a diagram to visualize the process better:
CI consists of 4 steps:
The CD consists of the following:
In other words, when the developer codes a feature, he 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 and test 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. Deployment does not occur if a problem is identified and developers are notified. If no errors are reported, the integration server can directly deploy the code in the production environment.
Thus, continuous integration fully integrates the automated testing phase into the deployment flow.
The main contribution of continuous integration is to guarantee a certain code quality in production and, therefore, better end-user satisfaction. Indeed, the test 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 of 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—there is no need to wait several weeks anymore to identify and correct errors.
Finally, continuous integration encourages teamwork. Often, several Developers work on separate tasks for the same project. However, a large team is more likely to introduce errors during integration. 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 developers are no longer afraid to "break the code" during each deployment.
Different DevOps tools are available to manage continuous integration, and 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 pretty simple to install, and more than 1000 plugins are available, allowing it to be integrated with most development, testing, and deployment tools.
Travis CI is a paid software for continuous integration published under an 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 is to Gitlab what Travis is to Github: an integrated end-to-end tool.
Bamboo is a continuous integration software developed by Atlassian. It is not free; the 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 relatively easy to configure and use.
All these tools offer similar performances. To choose the most appropriate one, it is better to consider your team's skills by asking yourself, "With which tools are my Devs most familiar?" The cost can also be used to differentiate these different tools.
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 they are well designed. Dev and Ops are thus more serene and able to deploy regularly.
Continuous Delivery and Continuous Deployment bring automation to a higher level. Continuous deployment is the practice of delivering each software change directly to end-users.
No human intervention is necessary. Unlike continuous delivery, everything is done automatically, which requires manual deployment action. Only changes that fail a test are not directly deployed in production. This practice speeds up the feedback loop and allows devs to focus on developing the application since there is no longer a release date to anticipate.
To conclude:
Do not hesitate to contact us if you have more specific questions or if you would like to provide us with additional information to complete this article.