Understanding continuous integration

Continuous integration (CI) is a set of software development practices for frequently integrating code changes. Each time a developer integrates changes (usually at least daily), those changes are automatically verified and tested. This means that there is always an up-to-date build ready to deploy.

The practice of CI was created to solve integration and compatibility problems caused by the old approach of developers working in isolation for an extended period on their version of code and then attempting to merge their changes into a shared code base.

CI follows the counterintuitive principle that if something is painful, you can make it less painful by doing it more often. This is based on the understanding that the integration effort is exponentially proportional to the amount of time between integrations (as found on https://martinfowler.com/articles/originalContinuousIntegration.html#TheMoreOftenTheBetter).

The next section describes how to bring these principles to your software development process.

How to implement CI

Here is a list of fundamental practices that a team should consider following to implement CI:

• Trunk-based development: As described previously, developers divide their own work into small batches and merge that work into the main code branch (trunk) at least once a day.
• Automated builds: For every change committed to the repository, the application is automatically compiled, built, and tested without manual intervention. This helps ensure that the software is always in a state that can be deployed to production. Artifacts produced by the CI build should be used by all subsequent deployment tasks. An automatic build is run at least once a day.
• Continuous testing: Automated tests run every time a change is committed, including unit tests, integration tests, and other types of automated tests. This helps ensure that new code doesn’t break existing functionality. Immediate feedback from these tests allows developers to fix issues quickly before those issues cause bigger problems. Tests should run successfully at least once a day, and if they fail, the team prioritizes fixing the problem.
• Collaboration: This is probably more a consequence of the previously listed elements than a principle to implement. With all team members committing to the shared repository regularly, there’s a continual exchange of ideas and code. This openness not only improves the quality of the software but also enhances team dynamics, as everyone can see what others are working on. It also encourages developers, testers, and operations teams to work more closely together. This collaboration breaks down silos and promotes a more cohesive approach to software development, in which everyone is aware of the goals and challenges of the project.

Now that we’ve covered the main elements of CI, let’s explore continuous testing.