What is Continuous Integration?
Continuous integration is a software engineering practice where all developers merge their working copies into shared mainline several times a day. The purpose of continuous integration is to avoid and prevent integration problems by ensuring that the main code repository is updated frequently and with small, incremental changes, rather than irregularly and with large changes. The idea for continuous integration was introduced by Grady Booch in the publication Object-oriented Analysis and Design with Applications.
Continuous Integration Benefits
Changes in the way that software developers approach application architecture have made continuous integration an increasingly popular methodology. In the past, the majority of software applications were built using what you would call a monolithic architecture. This means that the application is built as a single unit, or "all in one piece". A traditional enterprise application with a monolithic architecture is built in three essential parts: a database, a user interface and a server-side interface.
Today, an increasing number of applications are being developed using a microservice architecture. A microservice represents a specific feature of the application, a capability or service with a measurable business value. This means that features can be developed independently and even written in completely different programming languages. Development teams can enable feature toggling, making it easy to active and deactivate specific application features or microservices in the production environment. The microservice architecture model enables software developers to deliver new updates more frequently, as updates to individual services can be implemented without negatively affecting other parts of the application. This enables developers to take advantage of the benefits of continuous integration, which include:
- Better Fault Isolation - When developers implement continuous integration, it becomes easier to detect integration bugs at an early stage. Continuous integration ensures that changes to the main code repository are implemented frequently, so each update is small. When an integration error occurs, relatively few lines of code have been added since the last successful build, so it's much easier to find and diagnose the error. Additionally, for teams that use microservice architecture, faults can be isolated within individual microservices, making it even easier to debug.
- Lower Consequences of Failure - Sometimes a bug emerges and developers are forced to revert back to an earlier version of the code that is known to be functional. For teams that update the code base 10 times per day, this means reverting to the previous build from an hour ago. For teams that updates monthly, it means reverting to a build from a month ago or more. Frequent integration means that fewer changes are lost in cases where a revert is necessary.
- Current Build Always Available - Teams that practice continuous integration always have access to a highly current version of the software that contains the latest updates. This enables more timely testing, demos and faster releases.
- More Frequent Updates - Continuous integration ultimately means that software teams are delivering updates faster than before. This shortens the feedback cycle between application updates and user feedback and ensure that software development teams can continuously cater to the desires of their user base.
How to Implement Continuous Integration
Maintain a Centralized Code Repository - The journey to implementing continuous integration begins with the establishment of a centralized code repository for your application. The repository should contain all of the programming artifacts required to build the project with no additional dependencies. The goal of continuous integration is to make regular updates to the mainline code (at least once per day), ensuring that integration errors are immediately detected and corrected.
Write a Comprehensive Build Script
One of the most important best practices for continuous integration is automating the build process. Continuous integration teams require the capability to initiate a full build script that compiles binaries and generates documentation, web pages and statistics. Automating the build process is a necessary pre-condition for continuous integration that also helps developers save time and money by eliminating redundant tasks.
Automate Self-Testing of Your Application
Automated self-testing should be run on every build to ensure that the code continues to function as expected. When an error is found, it can be diagnosed and corrected through debugging or developers can revert to a stable version of the code while losing a minimal amount of changes.
Everyone Commits Updated Code Every Day
Committing new code updates to the mainline on a regular basis reduces the number of conflicting changes, therefore it is important that each developer on the team commits their updated working code at least once per day. We have heard of software teams that commit new code up to 10 times daily.
Every New Commit Should be Built
To ensure success in the integration process, every new commit should be built into the current working version and tested for function. This process can be automated withe the use of a continuous integration server that monitors the code repository for changes and automatically builds and tests when a change is detected.
Builds Should Always Complete Rapidly
Continuous integration teams need to ensure that their automated build process happens quickly. If the build takes 24 hours, that introduces a day of delays in finding any integration errors. Short build times mean that errors are identified and resolved more quickly.
Clone Your Production Environment for Testing Purposes
One of the aims of continuous integration is to ensure that the application is always functional and ready for deployment. When the test environment does not accurately represent a live or production environment, this is impossible to verify. Software developers should construct a "staging environment" that replicates the conditions of live production.
Streamline Access to the Latest Deliverables
Make sure that all stakeholders and testers can access the latest build to review and test code. Early testing and error detection can reduce the time needed to resolve a software bug.
Everyone Can See Build Results
Continuous integration teams need to maintain a constant state of transparency when it comes to build results. Separate teams should be able to see whether the build breaks, then trace that back to what was changed and who changed it, and what microservices are affected.
Automate the Deployment Process
The final step of continuous integration implementation is to automate the deployment process. Deployment can be to either a test server where the build can be reviewed by the development team, or to a live production environment where users can instantaneously give feedback on updates.
Continuous Integration and Continuous Delivery
Continuous delivery is the ability to deliver software that can be deployed at any time through manual releases. You may also have encountered the methodology of "continuous deployment", which is the ability to deliver software that can be deployed at any time through automated releases. Continuous delivery is similar to continuous integration in that it emphasizes test-driven software development and frequent code commits to the mainline - however, continuous delivery goes a step further by establishing the requirement that the code can always be released in its most current state.
Complete visibility for DevSecOps
Reduce downtime and move from reactive to proactive monitoring.