What is continuous integration (CI)?
CI aims to provide rapid feedback so that, when a defect is introduced into the codebase, it's identified and corrected as soon as possible. Additionally, this practice makes the software development process faster and more predictable by working in small iterations.
In CI, software developers regularly merge small code changes into a central repository, where automated code builds and tests are then run. Newly developed code is sent to a shared repository using a version control system, like Git. Next, a CI service automatically conducts testing processes -- usually, unit tests or integration tests -- on the new code changes. If the automated testing process finds a bug, the CI service blocks the software from progressing further, and the development team receives a report. The software is then quickly repaired. These code integrations are made frequently, sometimes multiple times per day.
Continuous delivery (CD) is another common practice that's used to expand on CI after the build stage by deploying those code changes to a testing or production environment. The two practices go hand in hand and are commonly referred to as CI/CD.
CI originated from within the extreme programming paradigm, which is a subset of the Agile methodology, but the principles can be applied to any iterative programming model. Traditional development approaches, such as the Waterfall model, can also benefit from the use of CI methods for the construction stage.
Importance of CI
Working on code for an extended period and only merging that code to a central repository when completed makes the merging process much more challenging and time-consuming. This process can result in more bugs, which take more time to comb through and fix.
Regularly merging small code changes instead is typically a more accurate and safer process. If any bugs are found in the merging process, they're easier and faster to find. The shorter feedback loop of CI also enables more code iterations.
CI also makes the process much faster by automating tests. CI tools can monitor the central code repository and accept or reject code commits.
When it incorporates CI into the development process, a software development team can bring worthwhile benefits to an organization, including the following:
- Shorter and less disruptive code integrations. CI features less code integrated at a time at a more frequent rate than other development approaches. Similarly, reverted changes are less disruptive, as only isolated changes go out at once.
- Faster and easier bug detection. If a bug surfaces, it will most likely be in the last integrated batch of code. This benefit is a result of increased code visibility, as software developers constantly add to the codebase.
- Feedback. CI enables continual feedback on changes, which can improve a product over time. The process makes it faster and easier to respond to feedback.
- Productivity. Software developers don't have to run a test with every code merge, as that process is automated. They can instead spend more time on other tasks.
- Testing. Tests run in CI help verify code correctness, validate application behavior, test code for security and run automated unit, integration or regression tests.
How continuous testing affects CI
Continuous testing is a continual and often automated software testing process where different test types are performed in the software development pipeline. Continuous testing is implemented to find bugs as soon as they appear in a codebase. The continuous testing process uses automated tools to load pre-made test scripts to validate source code efficiencies and to look for bugs. Each code change in continuous testing starts a set of tests to identify potential issues in the code. Feedback is provided to the relevant teams if an automated test fails.
Continuous testing is a critical component behind CI, as well as in the CI/CD process. Continuous testing accelerates software development time by improving code quality, while providing important feedback early in the software development lifecycle (SDLC) process.
CI common practices
According to Paul Duvall, co-author of Continuous Integration: Improving Software Quality and Reducing Risk, best practices of CI include the following:
- Frequent code commits.
- Developer test categorization.
- A dedicated integration build machine.
- Continuous feedback mechanisms.
- Staging builds.
CI releases can occur at any frequency, depending on the organization running the project. Generally, organizations that adopt CI release software more frequently than those using other software development processes. Each significant change kicks off a build. A development team incorporates CI for several reasons, including to receive constant feedback on the status of the software. CI detects deficiencies early in development, which makes them less disruptive, less complex and easier to resolve than later in the SDLC.
A development team can use automation in the CI setup process to incorporate code integration and testing, which reduces the time to find bugs and enables faster feedback than when these tasks are carried out manually. Automation tools help teams perform common tests as part of the CI process, such as unit, application programming interface (API) and functional tests. A unit test examines the smallest application components. An API test assesses whether or not an API can reliably perform under its expected load of requests and responses. A functional test typically evaluates larger pieces of the source code to simulate a user workflow or function. With full CI automation, scripts or integration engines manage the movement of new code through tests and build.
This automated approach is often an integral part of a CI/CD pipeline and a DevOps methodology.
A development team uses CI software tools to automate parts of the application build and construct a document trail. Many additional tools exist for steps in the CI pipeline, such as version control, testing, build storage and artifact storage. The following are examples of CI pipeline automation tools commonly found in enterprise IT shops.
- Azure Pipelines is a Microsoft tool that integrates with GitHub and Azure hosting tools. Azure Pipelines can test code and includes CD and continuous testing features.
- Bitbucket Pipelines is a CI tool offered by Atlassian that directly integrates into Bitbucket. This tool manages code commits and offers CD capabilities.
- CircleCI is a CI tool that integrates with GitLab and Atlassian Bitbucket. This tool is used to automate the steps included in building code, testing updates and deploying applications.
- GitLab is an open source repository and platform that supports CI/CD. It can run unit and integration tests on multiple machines and split builds to work over multiple machines to decrease project execution times. The software also supports manual deployments for CD to staging and production environments. GitLab also supports integration with tools such as Atlassian Jira, GitHub and Jenkins.
- Jenkins is an open source CI automation server that can distribute tests and builds over numerous machines. Plugins extend Jenkins' feature capabilities, such as those for automated unit tests and test reporting. A developer can create a project build via specific URLs, commits in a version control system, or a pre-scheduled and sequential system. Once a system is tested, Jenkins can deploy code with CD. CloudBees enables the use of Jenkins at enterprise scale.
- JetBrains TeamCity is an integration and management server for CI/CD. It enables software developers to test code before they commit changes to a codebase. If a test fails, the product sends a notification to users. TeamCity features build grids, which enable software developers to run multiple tests and builds for different platforms and environments. TeamCity includes support for Docker, Atlassian Jira and other programs.
CI and CD
CD is a process that occurs after CI, and the two processes are deeply connected -- commonly referred to as CI/CD. CD in CI/CD commonly refers to continuous delivery, but the CD acronym might also be used for continuous deployment -- as both versions of the term are commonly conflated:
- Continuous delivery takes code built in the CI stage and runs various tests for performance, security and usability. These tests are normally automated and include functional, user acceptance, configuration and load testing. If the build passes, it can be deployed with a trigger or button that requires human intervention.
- Continuous deployment is the process of automatically deploying the code to customers with zero human intervention. If the finished build passes tests, it deploys straight to production.
Both continuous delivery and deployment take place after CI, and either one of the two processes are used. The principal difference between continuous delivery and continuous deployment is that continuous deployment automatically deploys each validated build to production. By comparison, continuous delivery only stages the validated build for manual deployment. Continuous deployment, however, should be considered only if a team is confident that their code has zero chance of creating an issue.
Learn how to address five potential CI/CD implementation problems.