This page will guide you through everything there is to know about continuous integration. We’ll cover the nuanced differences between continuous integration, continuous deployment, and continuous delivery, explaining use-cases and best-practices along the way to automating the building and testing of your software.
What is continuous integration?
Continuous integration (CI) is a software development strategy that increases the speed of development while ensuring the quality of the code that teams deploy. Developers continually commit code in small increments (at least daily, or even several times a day), which is then automatically built and tested before it is merged with the shared repository.
Continuous integration: an overview
- Every developer commits daily, or even more often, to a shared mainline code repository
- Every commit triggers an automated build and test of the codebase
- If the build or any test fails, it’s repaired quickly – often within minutes
Continuous integration works hand-in-hand with Agile methodologies. Team members work on incremental “stories” and the code for these software changes is merged incrementally into the shared software repository multiple times a day.
Continuous integration can be used for many types of software projects. For example, we use continuous integration for updating the CircleCI website:
Developer or content publisher creates a new branch of code in GitHub, updates the HTML on the page, and then commits the changes.
When the developer has completed all the changes on the particular branch, they then create a pull request on GitHub.
GitHub is integrated with CircleCI. CircleCI runs the build processes on the code and then runs the automated test scripts.
If CircleCI encounters any errors (build status red), the developer is notified via email.
Otherwise, the user is notified that the build was successful (green) and that the code has been pushed to the staging server. This allows the developer to preview the web page.
Once verified, the developer can then merge the new branch of code into production.
What is the difference between continuous integration, continuous delivery, and continuous deployment?
The automated building and testing of your application on every new commit.
A state where your application is always ready to be deployed. A manual step is required to actually deploy the application.
The automation of building, testing, and deploying. If all tests pass, every new commit will push new code through the entire development pipeline to production with no manual intervention.
Continuous Delivery By Martin Fowler
Continuous Delivery vs Continuous Deployment By Jez Humble
Continuous Deployment By Timothy Fitz
Continuous Delivery By Wikipedia
What Is Continuous Integration? By Lev Lazinskiy
What is Continuous Deployment, Anyway? By Laura Franzese
A brief history of DevOps, Part III: Automated Testing and Continuous Integration By Alek Sharma
A Brief History of DevOps, Part IV: Continuous Delivery and Continuous Deployment By Alek Sharma
Continuous integration (CI) vs continuous deployment (CD)
Continuous integration automates the building and testing of your software. Continuous deployment is an extension of this automation and allows for your software to be deployed after every code commit that passes your test suite. The most successful development teams deploy their software often.
The software development process consists of three main centers of work:
Creation of the code: This is where the software development team is the most creative. They are turning user stories into elegant code.
Orchestration of new code as software: This is where the heart of continuous integration lives. Once the developer commits code, the continuous integration build server automates the build, test, and deploy process.
Logistics: This is the final step of shipping the new software to production. Tools in this part of the process monitor and manage the software in production.
The most important tool for the creation process is the repository used to hold the code. CircleCI integrates with GitHub and Bitbucket. Our server solution also integrates with GitHub Enterprise.
CircleCI lives in the orchestration center of the work. It does the heavy lifting of turning the code into working software. Users configure how the code is processed via a YAML file. The YAML file allows configuration via code and is almost infinitely configurable, allowing teams to build and test their way.
The logistics part of the software development process includes getting the tested and approved code into production. This includes the setup, configuration, and management of the production servers. To gain the full benefit of continuous integration, continuous deployment is necessary.
How to get started with CI/CD
It is important to get a continuous integration (CI) pipeline set up as early as possible in the development of your application. Once tests are added to your CI pipeline, you can continue to innovate and build with confidence knowing that you cannot merge code to main that doesn’t pass your tests. Additionally, developing a continuous deployment workflow into your CI pipeline provides the automation of deployment. With CircleCI, you can automate your software’s build, test, and deployment and your engineers can get back to work building the features that your users care about the most.
Make sure everyone is on the same page with respect to what you’re trying to achieve by introducing a new CI/CD tool.
Always start small. Don’t try to make your entire organization into a model DevOps team overnight. Instead, make process changes on one team to see if they work within your organization. If you see improvements, keep moving incrementally.
Do what works for you. Know that DevOps might not be the right solution for your organization. Some companies have been successful for a long time without DevOps, and it might not be right for them, given their culture or their product needs. For example, if confidentiality is a big part of your company’s product strategy, then shipping incrementally to get feedback would not work for you, as you’d need to keep all product details under lock and key until a big launch. In that environment, it would be very difficult to build a DevOps culture.
Always measure. Before you start any improvement plan, get accurate metrics for where you’re currently at (i.e. our dev cycle takes X amount of time). Do this before you’ve invited a site reliability engineer onto the development team. Then after a small amount of time, you’ll be able to see whether it’s been effective. As an example: When a lot of Agile transformation was happening, many companies adopted standups, without really understanding why, or measuring whether it had a positive effect on their team. This likely wasted more time than it saved.
Do not try to automate everything. At least not all at once. One misconception about DevOps is that all the infrastructure provisioning and the configuration management must be done automatically. This is referred to as “infrastructure as code.” But some things work better when they are manual; automation is not the solution for everything. Sometimes, you have to start the manual way to figure out what the best solution for automation actually is.
Continuous integration is not just about implementing a new tool. It is about changing how the development team works. It’s a new mindset. And, making culture changes in an organization is not easy. The best way to get started with continuous integration is to start small.
Use your next small project as a proof of concept and get the following fundamentals into place:
- A rigorous testing practice, ideally using automated tests.
- Consistent software environments, from testing to production.
- Training on continuous integration practices.
- Reports to measure key metrics.
Once your team starts committing regularly and in small increments, they’ll see how much easier it is to be responsive to bugs. And, as they resolve bugs faster, they will deliver features even faster. This will give your team the momentum to scale continuous integration across the organization.
What is the best continuous integration and continuous deployment (CI/CD) tool?
DevOps is a very specific collaboration between developers and operations teams. In essence, it indicates that you’ve culturally adopted development practices into your infrastructure, and operational practices into your development cycle. What does this look like in practice? It can mean maintaining infrastructure as code, or creating immutable infrastructure by building reusable components so you can tear down or up whenever you want, giving you version control and a history of changes you’ve made. It also means getting all product contributors to care more about the end result of what they’re working on—how does it function in the world? How are users interacting with it? Getting people to truly care about quality means caring about both business value and usability. That’s the result of true DevOps adoption.
This kind of widespread buy-in is particularly difficult for software teams to achieve because it requires a lot of cooperation from people with different skills and domain expertise. Pulling this off requires both cross-functional team structure and thoughtful communication. For example, if an engineer needs to talk to someone on the business side about a database problem, they need to not just show the data they’re working from, but give necessary context and focus that person’s attention on what they should care about and why.
So, should you bring in that new tool? The answer is: maybe. Tools can sometimes seem like a quick fix, but they are not a one-size-fits-all solution. Keeping these considerations in mind before you bring in a new DevOps tool will increase your chances of success. The best CI/CD tool is the one that works for your team.
Moving to DevOps: what tools do you really need? By June Jung
How to bring a new tool to your team (and not get squashed in the process) By Emma Webb
Update: How CircleCI processes over 30 million builds per month By Rob Zuber
Hosted vs on-premise continuous integration
We can host continuous integration for you on our cloud-managed option (SaaS) or you can run CircleCI behind a firewall on your private infrastructure.
We oversee the setup, security, and maintenance of your continuous integration instance(s), and we provide immediate access to feature releases and automatic upgrades alleviating the need for maintenance. Authorize with GitHub or Bitbucket and go from sign up to green build in minutes.
Install CircleCI on a private server that your team sets up and maintains for security. This provides full System Administrator control for complete customization. Your team determines the update cadence to fit your maintenance schedule.
Benefits of continuous integration
The fundamental tenet of continuous integration is quite simple: commit and integrate your code often—daily at a minimum. Such a small change in your software development process can yield big results.
Using this development strategy, you can:
- Improve team productivity and efficiency
- Accelerate speed to market
- Identify product/market fit
- Release higher quality, more stable products
- Increase customer satisfaction
- Keep developers happy and shipping code
How do these benefits accrue from such a simple change in your workflow?
When you commit more often, you can identify and resolve merge conflicts earlier, or avoid them altogether. So, instead of writing a thousand lines of code and finding an error, you’ve only written a hundred. Finding the bugs in your code becomes an errand of a few minutes instead of a few hours. This leads to improved team productivity and helps developers ship working code more quickly.
Shipping new features quickly means increasing your speed to market. This gives your team a competitive edge in two key ways:
Your customers are getting access to new features faster, leading to higher customer satisfaction
Your company is getting a faster return on investment from new features. Rather than waiting for the next milestone to release code, you can deliver value as soon as a new feature is ready for the market.
CI/CD for open source projects
CircleCI offers every organization on our free plan 400,000 credits per month to use for open-source Linux builds. To access this, just keep your repo public. If you’re building on macOS, CircleCI also offers organizations on our free plan 25,000 free credits per month to use on open source macOS builds. To get access, contact us at email@example.com.
Continuous integration best practices
Developers who practice continuous integration commit early and often. This allows them to detect conflicts before deploying code to production. And, having a smaller commit makes it easier to troubleshoot the code if there are any issues. Committing software daily, or even more often, is necessary for continuous integration, but not sufficient.
To use continuous integration successfully, the team must:
- Make testing an integral part of the development process. Tests should be written as code is created.
- Ensure that the testing environment mirrors production.
- Use coding best practices, such as pair programming.
- Automate the deploy workflow.
Fostering a rigorous testing culture is the most important element that a company needs for successful continuous integration. In order to confidently integrate new code into the mainline, the team needs the confidence that the code is sound. Engineers should write tests as each feature is being developed. At CircleCI, we run tests on any new code that is committed and our system alerts the developer if they have a successful “green” build, or if they need to fix issues because the build was “red.” Without tests, of course, green builds are meaningless. Ideally, the team is using automated testing, though that is not a requirement. QA services, such as Rainforest QA, can be integrated into the continuous integration process.
To support your rigorous testing culture, it’s important that the testing environment mirrors the production environment. Otherwise, you have no guarantee that what you’re testing will work in production. This means the testing environment should use the same version of the database, web server configuration, artifacts, etc.
Another best practice for software development is pairing during coding. For more complex pieces of functionality, pairs discuss the architecture approach before a single line of code is written. Before any code is merged into production, another developer always reviews the code. This helps ensure that coding best practices have been used, the code does not conflict with existing code or code that another developer is working on, and the new functionality is scalable.
Finally, to ensure that the entire software development pipeline is fast and efficient, the deploy workflow should also be automated. By automating the deploy workflow, the team gets their finished code to production more quickly. Because, after all, what’s the point of developing software quickly if it’s not getting to the customer?
Key metrics for tracking continuous integration
Continuous integration is a worthy goal of any software development team. But, how do you know if you’ve achieved your goal? This is where key performance indicators help. You need to measure the processes that make up the software development lifecycle in order to make improvements to it. This is how you will know if the changes to your process are making a difference.
Here are 4 key performance indicators (KPIs) to measure your software development:
- Lead time: Lead time is the length of time that it takes for your workflow to run from first trigger to completion. It is a measure of how quickly you can get a signal. A short lead time requires a maximally automated software development pipeline. That is why teams use continuous integration to automate building and testing. Automation of the pipeline via CI shrinks deployment timelines of weeks to months down to hours, if not minutes.
- Deployment frequency: How often your team kicks off a workflow is an indication of how many discrete units of work are moving through the development pipeline. With a fully automated software development pipeline, even complicated updates to your codebase can be deployed automatically. Hotfixes are available immediately — and they go through the same rigorous testing as any other update.
- Mean time to recovery (MTTR): Mean time to recovery is contingent on getting actionable information, fast. Getting a failed status returned quickly will enable you to get from red to green in the shortest amount of time. Adopting CI/CD practices enables rapid feedback loops, and is the best way to ensure fast signal for your developers. A robust CI/CD practice includes realtime artifacts such as logs and coverage reports from your test suite and gives devs the ability to troubleshoot in an environment equivalent to the production environment.
- Change fail percentage: The highest performing teams rarely push bad code to their default branch. But this doesn’t mean that these teams never write faulty code. Testing and security checks are performed on a separate branch and only when everything passes is a merge allowed to take place. A team should know that their code works well before it is merged into the default branch.
It’s helpful to have a regular cadence of reporting. Automated daily reports help ensure that if there is an error, the team catches it fast. And, analyzing the weekly reports allows teams to dive much deeper into the CI processes and find improvement areas.
Adding tests to your CI/CD pipeline
Let’s talk about the different types of tests:
These cover the smallest possible component, unit, or functionality. They’re the cheapest and fastest tests to run since they don’t require a lot of dependencies or mocking. These should be done early to get them out of the way.
These check how well each unit from the previous stage works with the other components, units, and functionalities. In a broader sense, it can test how services (such as APIs) integrate with one another.
UI layer testing
This is automated browser-based testing which tests basic user flow. It is expensive to set up and slow to run, so it should happen later in the pipeline.
Now let’s talk about how these tests fit into a software development pipeline. Each test has a specific role and place.