What is Continuous Integration?
Continuous integration is the practice of merging software code into an automated build process every time a new version is committed to source control. This triggers a series of automated tests that are performed before updates are added to the source code depository. In this way bugs, incompatibilities, and regressions can be identified and fixed rapidly—before they become a larger issue and disrupt workflow.
Continuous integration (1993) predates Agile philosophy (2001). Lean methodologies used in Agile share common traits with continuous integration practices, including shortened release cycles, automation, collaboration among the entire DevOps team, and continually improving a process to add value.
Continuous Integration vs. Continuous Delivery
Continuous integration is similar to continuous delivery, but different in important ways. Continuous integration (CI) refers to testing and verifying new code with the mainline build before adding to source control, then completing more tests before deploying to a staging environment. Continuous delivery (CD) refers to the practice of having software ready for release at any given time.
A development team may use continuous integration without continuous delivery. However, the continuous delivery pipeline cannot be implemented without continuous integration. Continuous delivery essentially expands the process of continuous integration to include release. When CD is implemented successfully (with CI as a strong component), delivery of software products is based on consumer demand and the state of the market at any given time—not development timelines or dependencies.
Continuous Integration Tools and Best Practices
When it comes to best practices for continuous integration, developers should:
- Commit code frequently
- Automate builds
- Make the build self-testing
- Use a dedicated integration build machine
- Implement continuous feedback mechanisms
- Test in a clone environment
- Notify all team members when a problem occurs
Tools are used in continuous integration (CI) for testing, automated builds processes, and version control. Some examples of these are:
- CI tools for testing – xUnit.net, NHunit, PHPunit and QTP.
- CI tools for automated builds – CI server CruiseControl and Jenkins, both open source and written in Java. There is also AWS CodePipeline in Amazon’s cloud.
- CI tools for version control – GIT.
Why is Continuous Integration Important?
CI is invaluable for DevOps teams who need to work at a fast pace and get feedback at regular intervals to discover bugs and regressions. It also aligns with core principles of lean practices in Agile, such as:
- limiting work-in-progress
- making incremental changes
- making workflow visible to all team members at all times
- encouraging collaboration
A single build per day was the standard in years past—but not anymore. To be competitive these days, enterprises need to continually release new software features and updates. CI allows this to happen by shortening the application lifecycle, updating source code often, and decreasing the number of bugs released with a new feature.
How to Successfully Practice Continuous Integration
A typical development scenario using CI can be illustrated in eight steps:
- A developer is assigned a task to update or change a piece of software.
- They grab a current copy of source code from the mainline and load it onto their local development machine.
- This working copy of code is updated and tested, and the developer will perform an automated build on their local machine.
- If the build is good, they test it against a new copy from the mainline.
- If there are no issues, the new build with code updates is committed to the source code depository.
- This new code is then tested on integration servers with mainline code.
- This process continues until the final updates are tested, verified, and ready to be put into a ‘near production’ environment for more testing.
- The final step is when the build is ready to be released into production.
With CI it is important to minimize branching of multiple versions of software from the mainline and to integrate changes to the source code often. How often integration occurs will depend on the DevOps team and complexity of the project, but it usually happens multiple times per day.
Getting Started with Continuous Integration
Application development is becoming more complex, and the time it takes to get from planning, development, and production to market is accelerating at a rapid pace. By applying CI and CD practices to Agile methodologies, DevOps teams can keep pace with the competition and ensure they are creating the most robust features possible.
For more information about CI in real-world development environments, check out our conversation with JFrog about continuous integration, software delivery, and architecting for microservices: Optimizing Continuous Integration and Delivery Using Advanced Analytics.
