Continuous Integration (CI) is the practice of regularly integrating changes into a repository of code. Rather than waiting weeks or months for a major development milestone to be reached before integrating changes, developers integrate their code changes as often as every few days or every few hours.
CI is certainly a change from the waterfall development methods of old. So why should developers so radically increase the frequency of their code integrations? It turns out that CI offers developers, QA teams, and others a long list of benefits. These benefits include:
Because changes are tested and integrated frequently, the risk of a new change derailing weeks or months of work is greatly reduced. In his popular introduction to Continuous Integration, Martin Fowler points out that CI eliminates the integration problems that used to plague waterfall development projects, when integration work would be difficult, prolonged, and nearly impossible to scope. Instead of wondering for weeks or months whether code would work, developers and QA teams get answers in days or even hours.
Improved code quality and faster troubleshooting.
Because CI helps developers identify bugs more quickly, they can fix bugs more quickly, too. Code quality improves. Projects no longer suffer from bugs that could have been found easily when they were created but have since been buried in successive check-ins. Because CI quickly exposes bugs to the light, developers and QA teams are spared extensive detective work down the line.
Because CI reduces the variation between the master and branches, it makes it easier for new team members to understand the code and how it’s being developed. When variations among branches are minimized, the software itself becomes easier to understand and extend.
Development teams can respond more quickly to requests from business units if a software project is always ready to be deployed, thanks to changes having been continuously tested, integrated, and staged for production. In nearly every market, competition is increasing, and everyone from product managers to CIOs is becoming more obsessed with agility (perhaps under the guise of something called “digital transformation.”) Business agility, of course, depends on developer agility. Today, developer agility depends on CI and CD (Continuous Delivery, which leads to the frequent deployment of integrated code). CI helps developers meet the ever-changing demands that businesses face.
Great. So you’re won over by these benefits and interested in adopting CI for your project. Now you’re wondering how to go about it.
There are standalone CI servers available that track code changes, check them into a repository such as Git, and flag any errors that result. But a standalone CI server becomes one more tool to manage. Most developers I know are trying to avoid adding more specialized tools if at all possible.
Fortunately, if you’re already using a Platform-as-a-Service (PaaS) development platform, you may be able to use the platform’s CI capabilities and spare yourself the hassle of standing up, learning, and maintaining a standalone CI tool. Here’s an example:
Heroku is a PaaS that offers a feature called Pipelines that makes it easy for individual developers and teams to adopt CI/CD. When you create an app, you can set up a pipeline that will make it easy to move the app through various stages to production.
For example, you can set up an app repository in GitHub and deploy the app in production on Heroku. To implement CI, you can create a new staging app in Heroku based on that same repo, and link it to the production app. Now you have a staging app that you can automatically promote to production.
Where Heroku CI really shines, though, is in an even earlier stage in the pipeline called Review Apps. The Review App stage is a complete disposable environment, including a unique URL, based on the same repository. Heroku spins up a review app automatically when a developer issues a pull request. The review app lets developers run tests earlier in the product life cycle, so they can discover and fix bugs more quickly. Because testing occurs at the Review App stage, developers can use staging to test multiple pull requests together, confident that each pull request has at least passed testing in isolation in the Review App stage.
So using Heroku Pipelines and Review Apps, developers can adopt this process for CI:
- Create a branch.
- Write code.
- Issue a Pull Request, which automatically creates a Review App and runs tests.
- Fix any problems uncovered by testing in the Review App.
- Merge pull requests and promote the branch to Staging (if applicable).
- Test the app in its Staging environment.
- Promote the app to Production.
With this model, Heroku is actually offering two levels of integration for CI:
- Individual contributors can integrate changes and run tests automatically with Review Apps
- Teams can merge changes and run tests with Staging Apps
This model allows developers to work quickly and independently, while giving teams a systematic approach to merging changes, confident that those changes have passed some initial level of testing in review apps.
You can see that this approach offers developers lots of benefits for moving to a CI/CD workflow. Using Heroku Pipelines, you can:
- Easily organize your development pipeline by deploying apps in Dev, Review App, Staging or Production environments.
- Enable developers to develop features in dev branches simultaneously, and test these branches with disposable Review Apps.
- Run tests on every push to GitHub.
- Automatically deploy updated code to Staging environments.
- Control who gets to promote code to Production. Promotion is quick and easy.
- Gain instant visibility to the entire development pipeline with the Heroku Dashboard.
Heroku Pipelines makes CI easier and more straightforward than ever before.
There are lots of reasons for adopting CI/CD development practices, including reduced risk and greater agility. Heroku Pipelines let you realize those benefits in a high-performance, scalable, and reliable PaaS environment.