Skip main navigation

New offer! Get 30% off one whole year of Unlimited learning. Subscribe for just £249.99 £174.99. New subscribers only. T&Cs apply

Find out more

What Is Continuous Integration?

With an understanding of DevOps, this article explains the first building block of DevOps, Continuous Integration.

Here, we look at what continuous integration is. We identify whether continuous integration processes have been established within the organisation and we discover the pillars and benefits of continuous integration.

What is Continuous Integration?

Continuous Integration is the process of automating the build and testing of code every time a team member commits changes to version control. CI encourages developers to share their code and unit tests by merging their changes into a shared version control repository after every small task completion. Committing code triggers an automated build system to retrieve the latest code from the shared repository and to build, test and validate the full master branch (also known as the trunk or main).

Continuous Integration as a best practice

CI emerged as a best practice because software developers often work in isolation, but also need to integrate their changes with the rest of the team’s codebase. Waiting days or weeks to integrate code creates many merge conflicts, hard-to-fix bugs, divergent code strategies, and duplicated efforts. CI requires the development team’s code to be continuously merged into a shared version-control branch to avoid these problems.

CI keeps the master branch clean. Teams can leverage modern version-control systems such as Git to create short-lived feature branches to isolate their work. A developer submits a pull request when the feature is complete and, on approval of the pull request, the changes are merged into the master branch. Then the developer can delete the previous feature branch.

Development teams repeat the process for additional work. The team can establish branch policies to ensure that the master branch meets desired quality criteria.

Teams use build definitions to ensure that every commit to the master branch triggers the automated build and testing processes. Implementing CI as described here ensures that bugs are caught earlier in the development cycle, which makes them less expensive to fix. Automated tests run for every build to ensure that builds maintain consistent quality.

Continuous Integration processes in your organisation

To establish whether your organisation has set up CI processes, ask yourself the following questions:

  1. Are developers in your organisation committing code multiple times a day to the source control repository? Are the same developers committing at least once a day to the main code line that is used to publish a code into the test environment?
  2. Do the commits that are done trigger a process of automated build and unit test execution?
  3. Do developers look at the results of the unit test execution?
  4. Are the developers constantly working towards improving code coverage from these automated processes?
  5. When the build goes red and fails, do the development teams stop what they are doing and fix the build within 10 minutes?

If you answer yes to all of these questions, your organisation’s CI processes are in place and have reached a significant level of maturity. If you answer no to any of these questions, you know that there are aspects that of the process that still needs to be developed

Three pillars of Continuous Integration

CI relies on three foundational elements, or pillars, for successful implementation. For each element, your team needs to select the specific platforms and tools that they will use, but you must ensure that you have established each pillar before proceeding. The three pillars of CI are:

  1. A version-control system
  2. A continuous integration system
  3. An automated build process

Benefits of Continuous Integration

There are several benefits of CI:

  • Improving code quality based on rapid feedback.
  • Triggering for automated testing for every code change.
  • Reducing build times for rapid feedback and early detection of problems (risk reduction).
  • Managing technical debt better and conducting code analysis.
  • Reducing long, difficult, and bug-inducing merges.
  • Increasing confidence in code-based health long before production.
  • Rapid feedback for code quality.

Possibly the most important benefit of CI is the rapid feedback that the developer receives. If the developer commits something and it breaks the code, he or she will know that almost immediately from the build and unit tests, and through other metrics.

Successful Integration

If successful integration is occurring across the team, the developer is also going to know if her or his code change breaks something that another team member did to a different part of the codebase. This process removes very long, difficult and drawn-out bug-inducing merges, which allows organisations to deliver in a very fast cadence.

CI also enables tracking metrics to assess code quality over time, such as unit test pass rates, code that breaks frequently, code coverage trends, and code analysis. CI can be used to provide information on what has been changed between builds for traceability benefit. It is also helpful for introducing anecdotal evidence of what teams do, to provide have a global view of build results.

This article is from the free online

Microsoft Future Ready: Continuous Integration Implementation

Created by
FutureLearn - Learning For Life

Reach your personal and professional goals

Unlock access to hundreds of expert online courses and degrees from top universities and educators to gain accredited qualifications and professional CV-building certificates.

Join over 18 million learners to launch, switch or build upon your career, all at your own pace, across a wide range of topic areas.

Start Learning now