What is CI/CD?

CI/CD Explained

What is continuous integration?

Continuous integration (CI) is the process of automating and integrating code changes and updates from many team members during software development. In CI, automated tools confirm that software code is valid and error-free before it's integrated, which helps detect bugs and speed up new releases.

What is continuous delivery?

Continuous delivery (CD) is the ability to push new software into production multiple times per day, automating the delivery of applications to infrastructure environments. CD is part of DevOps, which helps shorten the software development lifecycle.

How is CI different from CD?

Continuous delivery is the interim step of a software release pipeline that begins with continuous integration and ends with continuous deployment. The goal of these stages is to make small changes to code continuously, while building, testing, and delivering more often, quickly and efficiently.

Is CI needed before implementing CD?

Because continuous delivery is a logical next step in the software development pipeline after continuous integration, it makes sense to first have a CI process in place. Once software teams have automated the testing process, they can also automate the release process, followed by rapid deployment.

What are the requirements for CI/CD?

Software development teams need solid, tested processes for CI/CD, as well as testing solutions that meet the needs of the codebase. Also, teams need automation to deploy solutions so that they can eliminate the need for time-consuming manual deployment.

Stages of the CI/CD pipeline

Continuous integration

In this first phase, developers merge their code changes with primary code repositories for their projects. As developers push out code, they automatically trigger software builds.

Continuous delivery

This is the process of delivering the build to a run time environment for integration, quality assurance, or preproduction. In this phase, functional and performance tests are run against the application.

Since many teams work with multiple software development environments besides production, including development and testing, CD helps teams use automation effectively to rapidly push code changes to each environment.

Continuous deployment

In this stage, code is deployed to production environments, including public clouds and hybrid clouds. The deployment automatically launches and distributes software to end users. The automation tools move the tested and integrated software to places where it can be deployed to end users, such as an app store.

Steps for building a CI/CD team

Establish business capabilities

Understand what end users expect from products, since this dictates how software development teams will be aligned to enable these capabilities. A software solution may have many features, but some of them-or even just one of them-may be most critical to customers.

In these cases, some development teams may devote their team solely to updating and refining these features. Knowing end users' priorities, and which features deliver value to which audiences, helps teams focus on the most useful feature capabilities.

Understand processes, group portfolios

Once teams understand which features they need to deliver, and the relative importance of features in a product portfolio, the next step is gaining a deeper understanding of customers' processes. For example, what does their workflow look like? And how does the solution help them be successful?

Start groupings within a team by assets (also known as tools). Know which assets support each process and capability and group them accordingly. If none of the work has been done for a particular product feature, the group should start small-one capability at a time.

Software development teams should map capabilities to processes, then map processes to assets. They should also set goals for themselves along the way, such as one capability mapped per week.

Decide on people and places

After development teams determine how a portfolio will be aligned in a CI/CD model (that is, how a portfolio's assets will be grouped), teams should make decisions about who will work where. In this way, teams are aligned to capabilities.

It's a good idea to have no more than two geographic locations engaged together on a portfolio at one time. This improves availability and reduces complexity.

Decide on timelines and processes

With people and locations established, the next step is to decide on timing and how development teams will work with the business. CI/CD is considered a joint transformation for the business, so simply having IT run the process isn't enough to create change.

Choose a methodology

There is no single methodology that teams should choose for CI/CD; no option is one-size-fits-all. Ask internal clients which work styles makes sense for joint teams and that best suit the portfolio and assets. Try different approaches until teams find what works best for them.

Focus on change management

Risk-taking is part of the CI/CD journey. Create conversations among teams to challenge assumptions and ask questions. Approach each CI/CD challenge with discussions centered around, "How might we … ?" instead of, "We can't do that."

Create a plan for moving teams to a new delivery methodology. Provide input on what will and won't work, then test and retest the plan.

Benefits of CI/CD

More frequent code deployments

Organizations that build CI/CD pipelines can push out code faster. By standardizing builds, developing tests, and automating deployments, teams can devote more time to improving applications, and less time on the technical processes of delivering code to different environments.

Working seamlessly with many environments

As noted above, software development teams usually access several development and testing environments for testing and review of application code. With CI/CD, teams can still bring code to various environments without concerns about throwing projects off schedule.

Drives regression testing

With automated testing, which identifies when builds pass or fail, engineers can also move code through regression tests. Regression tests help ensure that code doesn't break a software build when it's merged with other trunks and confirm that code is working as expected.

It's a good idea to ask developers to run regression tests in all environments, so that developers only send tests to version control when all their tests pass.

Improved project collaboration and quality

Since developers who adopt CI/CD commit code more often, teams can quickly identify quality issues with smaller code packages, instead of larger ones created later along project timelines. Also, when developers have shorter commit cycles, they probably won't edit the same code and need merges.

Teams using CI/CD also tend to front-load their quality checks, like starting out with version control configuration and practice definitions. In addition to frequently checking code, developers will manage features and fixes on different timelines, and can then control which code and features are ready for production.

Better adoption

A well-built and feature-rich application isn't worth much if end users don't use it. CI/CD helps monitor uptake and usage of applications. It also allows teams to make constant improvements, such as changes to the user experience and the addition of in-app guides, to encourage users to use the application and its features.

This constant monitoring for improvement helps drive adoption even as the user base and usage patterns change.

Better user experience

Delivering a good user experience requires trial and error by development teams. Applications improve when teams monitor usage and make changes based on what they learn. When their observations show that users aren't clicking on a particular button or using a feature, software developers can move the button or feature until usage goes up.

If metrics show it's taking too long to load an image and users don't wait for it to load, developers can improve load times. In every case, continuous delivery creates the feedback loop needed to measure and improve user experience.

Reduced development costs

With a common, consistent set of development and testing tools, software development teams can avoid the extra costs associated with managing and licensing different applications. When CI/CD supports automation, teams gain economies of scale for developing and releasing applications.

More secure applications

Because CI/CD simplifies software development, teams can deliver higher-quality applications. Developers can also validate application security during development instead of waiting for the testing stage, helping to reduce or avoid rework of application code.

Higher productivity

The ability to integrate developers and processes through CI/CD can increase productivity and collaboration among teams working on a project, especially when those teams are scattered geographically.

Accelerates scaling

For organizations that expect to grow, CI/CD can easily scale by team sizes, codebases, and infrastructure. CI/CD can reduce code integration workflows that are no longer needed, thereby also eliminating unnecessary team communications.

CI/CD also helps reduce dependencies within teams, which means developers can work in silos on their features with the confidence that code will integrate without failing.

Generates feedback

Features move forward faster when teams get feedback on approaches. Feedback allows teams to measure results so they have firm evidence on which to base new projects. When teams get rapid answers on which workflows and approaches deliver successful builds, that knowledge goes into every future build.

Challenges of managing CI/CD pipelines

Automating too many processes

CI/CD should be an iterative process, and not every workflow needs to be automated all at once. Developers should create checklists to decide where and how CI/CD should be implemented, with questions such as:

• How frequently are the workflows repeated, and how long are they?
• Which team members are involved in the processes to be automated?
• What dependencies exist in each process?
• Do errors typically occur in the process?
• How urgently does the process need to be automated?

The responses can help teams prioritize which processes should be automated first.

Dashboards and metrics that matter

Teams often create CI/CD dashboards with indicators of progress (like green for good builds and red for failed builds) before determining what their colleagues really need to learn from dashboards.

The right way to create a dashboard is to first perform an assessment of the data that everyone wants and needs, and how they want it to look. For example, teams need to decide whether and how to use numbers, graphs, and colors to indicate status.

Balancing CI/CD tasks with resources

CI/CD tasks would normally be triggered whenever changes are introduced in code, but unnecessary processes will slow down progress and strain resources like CPUs and developer hours. To solve this problem, developers can break down software into smaller code packages so that pipelines run faster.