What is CI/CD?

CI/CD, or continuous integration/continuous delivery or deployment, is a software development practice enabled by automation. Frequent, reliable updates accelerate release cycles via continuous code delivery.

CI/CD explained

CI/CD is an umbrella term covering several DevOps phases. CI (continuous integration) is the practice of integrating code changes into a repo several times a day. CD has two meanings: Continuous delivery automates code integrations, while continuous deployment auto-releases final builds to end-users. CI/CD’s frequent testing reduces code errors and defects, making it crucial to every DevOps workflow.


Source code management

What is continuous integration? (CI)

Continuous integration (CI) is an automated software development process that increases the speed of development while ensuring clean, quality code with every deployment. Continuous integration requires developers to frequently checkin/commit their units of code to a central shared repository many times a day. 

CI is a DevOps best practice and stage in the DevOps lifecycle when developers checkin code to their shared code repository. An automated build tool verifies the checkin or branch to ensure there are no errors and that it’s ready to go into production. The main benefit here is that problems are usually caught early before they can snowball into bigger issues.

Practicing CI means integrating small subsets of changes in a shorter period of time, rather than substantial updates that take longer and less often. Automating workflows for testing, merging, and checking in changes to a shared repo means teams can deliver cleaner code at a faster rate. Cleaner code means faster validation, higher-quality releases, and a more efficient development pipeline that’s easier to scale.


How does continuous integration work?

Continuous integration is a simple and seamless process that begins in the development phase and ends in the testing environment. Continuous integration allows all developers to work collaboratively and keep track of their code. Every developer “commits” their code in small increments to a shared code repository, also known as the mainline repository. The code repository is maintained in a version control system like Unity VCS, Perforce, or Git. Every commit made to the repository’s main branch (or child branches if you choose) can trigger an automated build process linked to a build management system that takes the code and creates a build. Once the code is merged into the build system, the developers gain full access to their code builds. From here, they can see if their code is compiled correctly or if there is an error that they might need to fix. Build systems can be configured to support various testing frameworks. 

Once the code is approved and the build cycle is successful, an automated testing environment is triggered to validate the quality of the build and subsequent release. Because the test and build process is extremely quick, the results of the code commits can be communicated quickly, empowering developers to fix any remaining errors in a timely manner. This whole process ensures that the codebase stays healthy and everyone can continue to work efficiently.


Rules and principles of CI

Maintain one central code repository

Temporarily storing code from different developers in various teams into separate repositories or separate systems should be kept to a minimum.

Commit/check in code to the mainline repository frequently

The longer a developer holds onto code without building or testing it, the more likely it is to be inconsistent with what’s stored in the central repository.

Maintain separate build and test servers

Teams should maintain dedicated machines for build purposes only. This speeds up the build process and minimizes the impact on other developers' workflows.

Builds and tests must be automated

Every piece of code committed to the central source code repository should be built and tested automatically with continuous integration tools.

Use production-like testing environments

Testing environments should simulate the eventual production environment. This ensures the usefulness of the testing environment and keeps expectations consistent throughout deployment.

Quality assurance teams should have access to builds

When QA has access to builds, any failure to meet production requirements can be detected early,  reducing the risk of having to rework code builds later.


Continuous Integration Vs Continuous Delivery

Continuous delivery vs continuous deployment

Continuous deployment and continuous delivery are practices used to take new code and push it into production as quickly and efficiently as possible. Continuous delivery follows CI – you can think of it as a checkpoint phase in the development pipeline before the final product is released to customers. Once code changes have been validated, they’re automatically delivered to the central repository.

Continuous deployment follows CI in the DevOps lifecycle, but the two processes are linked. CI integrates code into the build with automation; CD completes that process. DevOps automations evaluate the quality of the updates. Once they’ve been found to be clear of errors, they’re automatically deployed to production.

What is continuous delivery?

Continuous delivery refers to the building, testing, and delivery of code changes to software. In this process, code passes through various testing environments, such as automated unit testing, integration testing, and system testing, before being pushed to production. Continuous delivery happens in production-like staging environments where QAs review the code, fix bugs, and run automated tests to ensure that builds are always deployable and release-ready.

With continuous delivery, the goal is to keep changesets small enough that no updates to the main build will compromise the final product’s “production-ready” status. The final product may contain minor errors, but nothing substantial enough to compromise the user experience.

Practicing continuous delivery means developers can spend less time testing in-house, as the practice ensures that only stable code makes it to the delivery phase in the first place. It makes bug detection a simpler process, accelerating time to resolution.

What is continuous deployment?

 Continuous deployment aims to continuously deploy code changes into production from the central repository once the build is stable. The operations team deploys the compiled code and installs the software in different environments (dev/test, staging, and production). Each change passes through an automated pipeline that pushes a working version of the application into production. Deployment can take different forms. A dark release is a deployment that’s hidden from users, while feature toggles or switches can be used to deploy specific subsets of a changeset to a group of users for testing and feedback.

Continuous deployment has numerous benefits for developers and customers. Devs using continuous deployment solutions no longer need to worry about manual build deployment and can focus on more skill-based tasks. Automation shortens feedback loops, which means products can be updated more quickly based on customer input. With continuous deployment, code is run and maintained in a simulated environment that ensures quality and enables real-time monitoring of the product.  The main goal of continuous deployment is to release newer versions of the code consistently and automatically deploy those changes to end users.


Benefits of CI/CD

Rapid iteration

Adopting CI/CD practices as part of your DevOps lifecycle speeds up development by automating the manual work of validating and deploying changes to the code base.

Cleaner code

Checking in numerous small changes throughout the day substantially reduces the risk of build-breaking errors being introduced into your source code.

Faster bug fixes

Merging smaller changesets more often with CI/CD makes it easier to identify code errors and fix them before they become a bigger problem.

Shorter feedback loops

CI/CD helps shorten feedback loops – a core DevOps principle – because smaller, iterative changes are easier to integrate, test, and deploy.

Better collaboration

CI/CD brings clarity to work by defining processes and timelines for code commits and build launches. With clearer goals, teams can move with greater agility.

Happier customers

Because builds are always release-ready with CI/CD, customers experience fewer service interruptions, and their feedback can be integrated much more quickly.

Similar reads

Explore more resources to learn about CI/CD and other DevOps solutions and processes.

Agile vs DevOps

Agile and DevOps have the same goals – delivering customer value through regular release schedules – but differ slightly in their approach. See how they can work together.

Benefits of DevOps

Implementing DevOps practices can streamline your development pipeline and make your team and users happier. Learn more about how DevOps can help you.

Understand source code management

Source code management (SCM) helps teams work quickly and collaborate efficiently. Learn all you need to know about version control tools, when to use them, and how they work.

Unity’s CI/CD solution

Iterate quickly and leverage powerful source code management and automation for your project with Unity’s CI/CD solutions. Choose Unity Cloud Build for distributed work, or scale your on-prem build capacity with Unity Build Server.

CI/CD Frequently asked questions

Is agile the same as CI/CD?

An agile workflow and CI/CD are related, however, they are not the same! They describe completely different aspects of the software development pipeline. Agile development, refers to the process or methodologies for managing workflows, meeting cadences, and team organization in software development. An agile methodology embraces change while accelerating delivery by listening and responding to customer needs and involving them in each stage of the development process.

CI/CD relies on automation to remove the human elements that create bottlenecks in releasing and improving the software. In both CI and CD testing is automated throughout the pipeline and is done frequently to minimize the costs and time it takes to remediate defects.


How often should you be deploying to production with continuous deployment?

With CI/CD, releases should always be frequent to avoid future problems and assure your software is always in a releasable state - typically deploying multiple times a day. A common assumption with CI/CD teams should be implementing "constant" releases, however, this is not always the case. Your release cycle can vary widely depending on your product, your builds, and other factors you might want to take into consideration such as:

Is it a critical or minor fix?

Are you tracking regression counts from build to build?

Is there a QA team put in place?

Does the code base have unit tests?

Are there any code duplications?

These are just a few examples of aspects to consider when thinking about a release strategy and pipeline, but it differs drastically from team to team. Different products require different approaches.

Is continuous deployment worth it?

There is no one size fits all answer to this question. Before investing in continuous deployment a business must first assess what the biggest risks are of their product and then determine the tradeoffs in how you want to deploy software. The success of your product is dependent on being able to quickly iterate, get feedback from your customers, and continue to make changes. Continuous deployment will be highly impactful and profitable if you are prioritizing shortening feedback loops and building a highly responsive business. However, if your business does not have many customers then the benefits of implementing increments of deployment will add less value and more costs. The staging environment you choose to deploy ultimately depends on your business needs, workflow, and budget.

Does continuous delivery encourage configuration as code?

Continuous delivery does encourage configuration because it continuously makes changes to the original code in the configuration. This ensures that the configuration stays up with code errors that may occur over time.

We use cookies to ensure that we give you the best experience on our website. Visit our cookie policy page for more information.

Got it