Getting Started with Continuous Integration (CI)
by Riversafe
Although it’s been around for a long time, continuous integration has become increasingly popular among development teams in the past few years.
One of the central practices in the DevOps methodology, continuous integration encompasses the automation of integrating, building, and testing code in regular increments.
Continuous integration is a solid starting point for any organisation looking to adopt a DevOps approach, partly because once CI has been implemented, the pipeline can be extended to include other aspects of DevOps like continuous delivery and continuous deployment.
Ready to get started with continuous integration? Let’s take a look at how to create your own CI pipeline to give your development process a boost.
What is continuous integration (CI)?
Let’s nail down the basics first. What is continuous integration exactly?
Continuous integration is a practice used within software development, most commonly among teams using the DevOps approach.
The continuous integration method involves members of a DevOps team uploading the code they’re working on to a shared code repository (integration). Once each developer has committed their code to the repository, the software is built and tested using automation.
The ‘continuous’ part refers to how often these integrations happen: at least once a day, but often more frequently than that especially in larger teams with more developers.
In short, continuous integration is the constant sharing of code changes into a collective code base, merging code changes made across the team on a regular basis so that it can be integrated and automatically checked for errors and against pre-defined quality standards.
CI vs CD vs the other CD
You’ll often hear about continuous integration alongside continuous delivery and continuous deployment (both commonly referred to as CD). Together, these practices are known as CI/CD.
Continuous integration, delivery, and deployment are all methods used within the DevOps approach to automate aspects of software delivery and get products and updates out faster.
Code changes that pass the automated tests in the CI stage are integrated into the most recent build. This build then moves into the staging phase. Most DevOps teams also extend the use of automation to this task. This is known as continuous delivery; the automated delivery of a release into a staging environment once changes have been merged and tested.
With continuous deployment, all changes that have passed necessary tests are then automatically deployed into production with zero manual intervention.
Any three methods of these methods can be used individually, but are most often used together, harnessing the power of automation and working in small batches to push small, regular changes out to the customer.
What are the benefits of using continuous integration (CI)?
Bugs are found and fixed sooner
Integrating code to a shared code base regularly means that code can be continuously tested and checked for errors—before more code is built on top of a buggy foundation, causing more problems further down the line. Finding and fixing issues regularly is a much faster and more efficient way of doing things, allowing developers to rectify things quickly and return the code to the repository to be retested.
And because CI usually uses some form of automated testing, code can be reviewed more quickly and more thoroughly by eliminating the chance of human error.
Large, cumbersome integrations are avoided
Integrating small batches of work reduces the time it takes to get feedback on changes, making it easier to triage and remediate problems.
Products get to market faster
As with almost all DevOps practices, the primary goal of CI is to deliver quality software faster. Continuous integration allows code to be amalgamated and reviewed more quickly, reducing lead time and increasing deployment frequency. This enables a team to ship changes and generally get products into the world faster. And the faster an organisation can deliver a (quality) product, the more competitive it will be within its market.
Lower risk of issues post-launch
Continuously sharing, reviewing, and fixing small batches of code makes it less likely that bad code slips through the net and into production. And the cleaner the code that gets released, the less likely it is that issues like downtime or security vulnerabilities will crop up with the live product. As well as making for happier customers, this also means developers will need to spend less time working under pressure to fix buggy code in a live product.
Overall better quality code and products
Continuous integration is all about failing fast. Maintaining a constant loop of integrating and testing code allows developers to address issues in near real-time, ensuring the code that eventually makes it to the release stage is thoroughly tested and of good quality. After all, small, regular changes are far easier to manage than trying to tackle big issues that crop up during ‘integration hell’, right before the release deadline.
What does a typical CI pipeline look like?
This cycle is repeated throughout the development phase, until all the code has been validated, merged, tested and a release-ready application has been built.
At this stage, continuous delivery and continuous deployment can also be implemented to automate the final stages of the development cycle.
Getting started with continuous integration (CI)
1. Set up your version control system
Before you can start building your new continuous integration pipeline, you need some essential tools in place.
Firstly, you’ll need a version control system (also sometimes known as source control or source code management systems) to track and integrate the DevOps team’s changes. These tools allow you to keep all code together and see every change made, when, and by whom.
It’s worth noting before you start your search for the right VCS that there are two types: centralised and distributed. A centralised VCS is often simpler to use (especially for those new to CI), while a distributed VCS offers users more flexibility by giving each developer their own copy of the repository which can be worked on offline.
Popular VCS tools
| Centralised | Distributed |
|
|
Once you’ve decided which platform will best suit the needs of your team and your pipeline, it’s time to set it up. This should be a one-stop shop, accessible to everyone on the team. Don’t just store your code here; everything related to the build should be in one place to maximise efficiency. Test scripts, install scripts, data files, properties files—it all goes in the VCS.
2. Automate building and testing
Whenever code is pushed to the repository (often multiple times a day), it needs to be built, deployed to the test environment, and validated. This process can be automated by using infrastructure as code to create and deploy environments frequently and reliably.
Once the testing environment has been successfully deployed, automated test scripts can be executed to check the code for bugs. For this stage of the pipeline, you can implement testing tools to run unit, integration, system, and performance tests, to name just a few.
Popular building and testing tools
| Build | Test |
|
|
3. Integrate changes regularly
Get your team into the habit of making small, regular code commits—every few hours is a good schedule to start with. This will help developers get used to the new pipeline, and into the habit of writing, integrating, and reviewing code in modest chunks and making regular fixes.
4. Automate deployment
With CI, applications need to be moved frequently between environments for testing. Automating the deployment of applications and their transitions between these environments will help create an efficient pipeline.
Popular deployment tools
- Azure DevOps
- Jenkins
- GitLab
- AWS CodeDeploy
5. Track your metrics
Getting the most out of CI means adopting another key DevOps philosophy: continuous improvement. You should be constantly reviewing the effectiveness of your CI pipeline, learning as you go, and optimising your processes.
You can’t improve what you don’t measure, so setting KPIs and measuring your pipeline’s performance over time is essential.
Which metrics are most important to you will of course depend on the objectives you’re looking to achieve by adopting CI. But if you’re looking for a place to start, a few common CI KPIs used by DevOps teams include:
- Code Coverage: How much code is covered by testing frameworks?
- Test Coverage: How much of the application’s functionality is covered by tests?
- Code Quality: How many errors like duplicated lines or vulnerabilities are flagged during static code analysis testing?
- Cycle Time: How long does it take the team to create and deliver a functional application that’s providing value?
- Time-to-Value: How long does it take to release code once it’s written?
- Defect Escape Rate: How many bugs are reported by users after the application’s release?
- Uptime: What percentage of the time is the application available and working as it should?
Need a hand?
Our DevOps consulting services have been designed to match where you are at in your DevOps journey. From just starting out, to a fully integrated DevOps practice, our experts can help you to improve the efficiency of your software delivery process. We work closely with you to understand your unique requirements and implement solutions, tools and processes to deploy applications quickly and securely.
We’re trusted by some of the world’s biggest companies to help improve the efficiency of their software delivery process through the adoption of DevOps.
Find out how we can help you get started with continuous integration, wherever you are in your DevOps journey.
By Riversafe
Experts in DevOps, Cyber Security and Data Operations
