What Is Continuous Integration?
Continuous Integration(CI) has now become a cornerstone for the successful implementation of DevOps as well as the Agile methodology of software development.
By definition, it is the practice where the developers integrate their code changes to a shared source code repository multiple times a day to ensure that the repository reflects the latest changes at all times. The practice is also extended to automatic creation of the build and execution of automated tests that test the code to make sure that the integration does not break in the process.
Importance Of Continuous Integration
On successful implementation, continuous integration helps to achieve multiple goals that help enable timely releases to the market keeping the quality intact. Continuous Integration becomes quite a necessity If there is a team with multiple developers that are checking in their code into the shared repository.
Below are some points that make it important and beneficial:
With continuous integration, the source code repository remains at the latest every day.
The developers are always in sync about the latest changes in the main branch.
Any issue in the main branch is reported at the earliest.
It gets easier for the developers to pinpoint the reason for a bug as the change that broke the build can be easily ascertained.
The developers don’t need to spend a lot of time to get to the latest version of the main branch.
There are no surprise bugs waiting to be uncovered at the end of the software development lifecycle as bugs are caught the time they are introduced.
Finally, the time to release is also reduced considerably as a lot of developer’s time is saved that could have been otherwise spent on debugging for bugs found later in the test cycle and to resolve any conflicts in code.
What Continuous Integration Does?
There are a few changes that happen when continuous integration is implemented by a team following software development methodology:
The check-ins to the source code repository are higher in number and more frequent.
The time spent in resolving merge conflicts reduces.
The number of bugs caught early in the cycle increases.
There is a definite increase in the visibility of the development and testing being done.
Everything that matters starts being reported - test coverage, number of test cases run, number of test cases passed, number of test cases failed, reasons of failure, number of check-ins, last check-in time, build success or failure status.
Importance of the quality of the software increases.
How Can Continuous Integration Be Used?
CI or Continuous Integration is a process and for a team to be able to use it effectively, there are some steps that need to be followed for its setup and some ground rules that need to be set for use.
Below is how the process looks like:
A successfully implemented continuous integration process looks like below in terms of steps:
Integrate Code: The developers integrate their code to the source code repository at least once daily.
Approve Code: After the code is integrated, there should be some approval mechanism in place to make sure that the source code did not have any bugs after the latest integrations. There could be multiple approval stages that can be put in place here, some of which are:
Codescan: The code is scanned for correctness and any unused code or wrong format or coding standard is reported.
Automated tests: Test cases to test the code are put in place that are executed every time some code is checked in.
Repeat steps 1 and 2
To set up an efficient continuous integration process, below steps need to be performed:
A version control system needs to be set up such that every check-in can be treated and stored as a separate version. Few majorly used VCS are Git, mercurial, subversion.
A version control hosting platform that can host the code with VCS functionalities is needed above the VCS.
A Single Source code Repository should be set up.
The process of building the code should be automated.
There should be tests in place to verify the correctness of the code.
Every Developer should commit to the mainline at least once daily.
Every Commit Should Build the Mainline on an Integration Machine.
If the build breaks, the fix should be done immediately.
At all times, it should be ensured that the build creation process should be fast.
The testing should be done in an environment that is a close copy of the Production Environment.
Below is what continuous integration can be used to achieve:
To speed up the build process
To improve the quality of build from the start of development
To make quality feedback loop better and quicker
To keep developers in sync with the mainline changes and avoid wasting their time in merging too many conflicts.
Continuous Integration Vs Continuous Deployment Vs Continuous Delivery
Continuous Integration, Continuous Delivery, and Continuous Deployment are the terms used to signify the automated processes of “Integration”, “Delivery” and “Deployment” respectively.
Continuous Integration is a combination of regular integrations from the developers on the source code repository and steps to approve the integrations.
Continuous Delivery is “automated release process” added to the continuous integration process which means that after the integrations done by a developer are approved, they are prepared into a build that is ready to be deployed. These builds can then be deployed as and when needed.
Continuous Deployment is the “automated deployment process” added to continuous delivery which means that after the builds are automatically prepared they are also deployed to the production every single time.
What are the benefits of each practice?
Benefits of Continuous Integration:
Errors are detected early-on.
Bug Count later in the cycle is reduced.
Because most of the testing effort is automated, the manual testing effort reduces.
Reports are sent for the status of build and tests, hence, the state of the code at any time is known by the stakeholders.
The time and efforts saved in the long run save costs too
Benefits of Continuous Delivery:
Since the product is ready to be deployed when needed after proper testing, the risk and downtime for deployment on production are reduced to a minimum.
With Continuous Delivery, the time and effort that was spent on enabling frequent releases is saved and makes the team efficient and focused on the important stuff and results in a better product.
Benefits of Continuous Deployment:
A completely automated deployment results in lower stress for the team.
Minimized friction for shipping improvements and fixes as now the complete deployment flow is automated and manual effort is greatly reduced.
No need to wait for a long time to ship small fixes, even small fixes can be seamlessly deployed.
Easier to deploy a bug-fix because the deployments are being done after small changes that can be easily debugged and fixed if needed.
Benefits And Challenges Of Continuous Integration
Continuous Integration has been a key process in the DevOps industry for some time now, and it is not without reason. Some benefits of practicing continuous integration are as below:
The build process speeds up because developers integrate their code to the source code repository once a day at least.
The quality of the build begins improving from the start of development because test cases to test the code are put in from the start.
Makes quality feedback loop better and quicker. If any code check-in by a developer breaks the code or fails some test, it is known soon after the integration and test cases are executed. Then the bug is fixed before the next integration is done.
Keeps developers in sync with the mainline changes and avoids wasting their time in merging too many conflicts.
Challenges of using/implementing continuous integration are as below:
If there was a complex workflow already set for traditional development, moving away from it could become a challenge for the developers and the product. So, in such scenarios, the transition should be taken slow and precautions should be put in place before going for the jump.
Too much feedback can create an atmosphere of fear. Every integration done by a developer goes through approval steps in continuous integration that means feedback will be provided for every step that goes right and every step that goes wrong. If the culture is not set correctly and developers are not sure that the failures will not be taken against them there will be an additional pressure of maintaining an image with every single integration into the source code.
Too many errors and reports can be overwhelming. Continuous Integration enables automated test execution and reporting every time there is a check-in by a developer. This may result in too many reports being sent. Too many reports could prove to be distracting for developers and they may end up ignoring them. So the number of reports being sent should be limited. For eg. The complete report could be sent once a day or when there is an error in the process.
CI(Continuous Integration) requires discipline to be implemented successfully. It is a process that can only be successful when every step of it is done regularly which includes check-ins by the developers, addition of test cases for proper test coverage, reporting of any errors, build creation. If any of the processes in the pipeline slows down it also slows down the complete process.
Getting Started With Continuous Integration
To get started with Continuous Integration, take below steps:
Start putting checks in place for testing and approving the code, for eg. writing test cases to test the code.
Setup a main source code repository over a version control system
Install a CI(Continuous Integration) service to run tests automatically after every integration.
Ensure that the check-ins happen regularly, at least once every day by every developer on the team.
If there are any errors or failures encountered they should be fixed without any delay.
For every new feature or a change to the code, new tests should be added if needed.
How Does Continuous Integration Work?
Below are the main steps that go into the working of the Continuous Integration Process:
A developer checks in the code to the main repository.
The code builds to check on any compilation or integration issues.
The automated tests are executed to test the code.
A report of the result of the test execution is sent to all the stakeholders.
If the tests pass, an executable is created and shared and a developer is free to do another check-in.
If the tests fail, the concerned developer works on a fix and a fix is checked into the system and again the same process can start.
Why Employ Continuous Integration?
There are few main goals for most of the software development companies these days, those are as below:
Quick releases
High Quality
Low Cost
Easily customizable code
Because of the above requirements, the agile methodology for software development is widely adopted. To make the implementation of agile methodology a success and realize the above requirements, the practice of continuous integration is being taken up by the majority of organizations.
If you are following agile methodology and feel that following traditional integration methods is getting challenging, for eg. developers are spending too much time figuring out the problem after there were multiple merges from multiple developers, Or developers don’t remain in sync while working on different features. Continuous Integration is what you need to employ.
Continuous Integration Best Practices
To achieve the best results, there are few continuous integration best practices that are recommended to be followed:
The code should be maintained in a Single Source Repository.
The Build creation process should be automated.
There should be test cases in place to test the code after every check-in.
Developers should commit to the source code repository frequently, one time a day at least.
To strike-out any environment-specific issues a build should be created on a separate and clean integration machine after every commit.
To make sure that the process does not slow down, any errors that are caught during the approval steps should be resolved quickly.
Fast build creation. Build creation is the last step of continuous integration and is the signal for the developers to know that their check-in is good. To enable efficient continuous integration process, quick feedback is essential.
Test in an environment that is a clone of the production environment. If tests are done on an environment that is not close to the production environment, there could be issues that are not there in the production environment and vice versa. Thus there should be a staging machine that has data identical or very close to the production data and tests should be run on that machine for approval of a check-in.
Continuous Integration And Continuous Delivery
When developers do their integrations to the mainline frequently it becomes Continuous Integration and when these changes are always ready to be deployed to production it becomes Continuous Delivery. Thus, Continuous Delivery becomes the next step to Continuous Integration.
Continuous Integration Tools
Some CI tools are as below:
Jenkins:An open-source, platform-independent Java-based CI tool. It can be configured via a console or a graphical user interface.
TeamCity:A cloud-based CI server, developed by JetBrains.
Travis CI:One of the oldest Continuous Integration solutions, the tool is free for open source projects.
Gitlab:Cloud-based CI developed by GitLab.
Circle CI:A cloud-based CI tool.
Codeship:Cloud-based CI tool for GitHub.
Comparison Of Continuous Integration Software
| Tool | Paid/Free | Operating Systems | Hosting |
|---|---|---|---|
| Jenkins | Free | Cross-platform | On-Premise Or Cloud hosted |
| Teamcity | Paid | Windows, macOS, Linux | On-Premise |
| Bamboo | Paid | Cross-platform | On-Premise or hosted on bitbucket as cloud |
| Travis | Paid | Linux, Mac OS | On-Premise or Cloud Hosted |
| Circle | Paid | Linux, iOS, Android | Cloud Hosted |
| Codeship | Paid | Windows, macOS | Cloud Hosted |
Continuous Integration (CI) vs Continuous Deployment (CD)
Continuous Integration is a combination of regular integrations from the developers on the source code repository and steps to approve the integrations. When the developers integrate their code to the single source code repository frequently and receive feedback about the quality of their check-in in an automated way, the practice becomes continuous integration.
When the “release process” is added to the pipeline in addition to continuous integration it becomes continuous delivery. Here, the builds are automatically created after every check-in and are ready to be deployed to the production when needed.
How To Maximize The Value Of Continuous Integration And Continuous Delivery (CI/CD)?
Continuous Integration and Continuous Delivery are one of the most important practices in the software development lifecycle that aim at making the integration and deployment quick and error-free.
Few best practices to maximize their value are as below:
A quick and reliable pipeline. The basic premise of CI/CD is frequency, speed, and reliability. For their success, it needs to be ensured that a single iteration of CI/CD does not take a long time. This includes making sure that the execution of automated tests, build creation time don’t take a long time.
The CI/CD environment’s security and accessibility should be given high importance and taken care of appropriately because all the information related to the development and a product is available in the environment at all times.
The CI/CD pipeline should become the only solution for deployment. For effective implementation, it is essential that the CI/CD pipeline is used and improved for deployment every single time. If there are other ways of doing it, the other ways might be taken up instead of improving the CI/CD pipeline when needed which could culminate in failure of CI/CD.
The automated testing environment should be as close to production as possible for the results to correspond with the production environment.
During all stages of the CI/CD pipeline, the code should be built once on a clean machine and then reused in later stages, this avoids injection of any new issues due to differences in environments.
To provide feedback as early as possible, prioritize the execution of high priority and fast test cases first.
The number of branches from the main source code should be kept to a minimum at all times to make sure that all the code is always tested and CI/CD is always used to maximum effectiveness.
To make sure there are no trivial bugs introduced in the mainline that may block other developers encourage developers to run the automated on the local environment first. For this to be possible, the automated tests should be easy to run via a single command on a machine.
The automated tests should be run on clean environments such that tests don’t fail because of complications created by different applications installed on the system.
Continuous Integration(CI) Vs Continuous Delivery(CD)
Continuous Integration is a practice where code is checked in by the developers on the source code repository regularly and after every check-in, there are automated steps to approve the integrations. The integrated code is usually tested with the help of automated test cases that are executed after every check-in.
Continuous Delivery is “automated release process” added to continuous integration process which means that after the integrations done by a developer are approved, they are prepared into a build that is ready to be deployed. These builds can then be deployed as and when needed
Getting Started With Continuous Integration And Continuous Deployment
To get started with Continuous Integration and Continuous Deployment, take below steps:
Start putting checks in place for testing and approving the code, for eg. writing test cases to test the code.
Setup a main source code repository over a version control system
Install a CI/CD(Continuous Integration and continuous deployment) service to run tests automatically after every integration
Ensure that the check-ins happen regularly, at least once every day by every developer on the team
If there are any errors or failures encountered they should be fixed without any delay.
For every new feature or a change to the code, new tests should be added
After every check-in, automated tests should be run
If the automated tests pass, use the CI/CD service to create a release build for every check-in.
After the build is created, have an automated system in place using the CI/CD service to deploy the build on production
Which Is The Best CI/CD Tool?
Jenkins, today, is the most used CI/CD tool. It is also free and can be hosted on the cloud or used on any operating system. This is also an open-source tool and has elaborate documentation and help available on forums. Check out how test it is implemented in Testsigma
Hosted Vs Non-Hosted Options
When choosing what tool to use for CI/CD, sometimes choosing between hosted i.e SAAS tools or non-hosted ones that are hosted on your own premises becomes a challenge. Below are the pros and cons of both that can help decide:
No need to maintain a dedicated hardware infrastructure
No need to worry about software updates and patches
Easily configurable
Easily scalable
Costs increase linearly as the team scales
The hosted options may not support all technologies and platforms if you decide to grow in the future
Could be easily extended to fit your needs
Can support multiple platforms and technologies when the need arises
Costs can be kept in check
Dedicated hardware needs to maintain on-premises
The hardware also needs software updates and patches to be taken care of
Though this is extensible, this also means that they will require more time and effort to set up
CI/CD For Open Source Projects
Below are a few tools that have become popular in use with open source projects:
Jenkins
Travis
Gradle
CircleCI
Codeship
GitLab
Buildbot
Key Metrics For Tracking CI
Time to production:Initially measured as the time for one continuous integration cycle, this is typically the time between when the work on a feature starts and when it gets deployed to production.
Number of bugs:The number of bugs being reported with every CI cycle should be measured and compiled as a stat. Any area that gets broken consistently represents poorly written code and should be revisited by the developers.
Defect Resolution Time:This represents the quality of code and the commitment of the team to quality at the same time.
Regression test duration:This is the time taken on an average to run the regression tests for a cycle. Ideally, all the tests should be executed for every cycle but are reduced according to priority and time taken by the regression tests to execute.
Broken build time:This time should be kept at the lowest possible to keep the continuous integration practice intact.
Number of code branches:The number of code branches should be kept to a minimum to ensure all the code gets tested and not a lot of resources are used for doing that.
Production downtime during deployment:With the target to achieve zero downtime for deployment, this statistic should be measured and reduced with time.
Adding Tests To Your CI/CD Pipeline
Adding automated tests to your CI/CD pipeline is an important step to ensure that every build receives timely feedback on quality. These tests should be run soon after the integration to the mainline is successful. The report of the test execution should be shared with all stakeholders and any breakages or bugs introduced should be fixed as soon as possible.
Some best practices for adding tests to a CI/CD pipeline are:
The tests should be independent of each other so that one error does not fail other tests.
One test case should test one condition such that all possible errors are reported in one cycle.
All errors reported by the test cases should be easy to understand.
It should be possible to execute all test cases via one command such that they can also be run by developers easily on their local machine when needed.
New test cases should be added to the pipeline whenever new code is added by developers.
The code covered by the test cases should be measured and kept to the maximum possible.
Redundant test cases should be removed regularly.
All test cases should be kept up to date at all times.
Any failures in test cases should be fixed on priority to keep the test cases relevant and useful and also to keep the CI/CD pipeline efficient.
Why Do We Need Continuous Integration?
Continuous Integration, when put in place, has a lot of advantages which are:
Developers are more in sync with each other because they need to integrate their code to the source code repository at least once daily.
Developers receive feedback on each integration they do. If there are bugs introduced they know what integration introduced them.
Any bugs that are introduced are solved quickly by the developers concerned.
Developers don’t need to spend too much time resolving conflicts caused by other developer’s fixes.
If your team has been facing any one of the problems as below, continuous integration is the solution you need to employ
Developers are spending too much time figuring out whose check-in broke the code
Developers spend a major chunk of their workday resolving conflicts caused by some other developer’s check-in
Major bugs are being found in the final stages of software testing and close to the release.
Developers need to wait a long time to receive feedback on the features and bug fixes they worked on.
Prerequisites for Continuous Integration:
Every part of the code should be maintained under version control before continuous integration can be implemented
All parts of code build and test execution should be automated and should not be manual or dependent on some constant like a machine setting or something.
Continuous Integration as a practice can only be successful when the team agrees to follow it, hence before implementation agreement from the team is essential.
The Goal Of Continuous Integration
The goal of Continuous Integration is to automate the integration and testing of every change done to the code base of a product and provide feedback for every change as soon as possible such that any bugs introduced can be fixed before any new changes are made.
Merits of DevSecOps Approach
Better speed and agility for security teams
An ability to respond to change and needs rapidly
Better collaboration, communication, and transparency among teams
Quality assurance testing
Early detection of vulnerabilities in code
Frequently Asked Questions
What is continuous integration in DevOps?
Whats the main purpose of continuous integration?
What is CI/CD? What does CI and CD mean?
What is CI CD?