The Business Case for CI/CD

How the implementation of an end-to-end pipeline can enable a more efficient software development lifecycle

What it Does Icon

What it Does

CI/CD is a methodology that enables optimization of software development stages based on agile processes and an end-to-end pipeline.

Benefits Icon

Benefits

  • 50% or greater reductions in software deployment time.
  • Doubled, or even quadrupled, frequency of deployment.
  • At least a 25% improvement in build times
  • 40% to 70% overall cost savings.
Urgency Icon

Urgency

High: Implementing CI/CD is urgent for automation of building, testing, and deploying applications in in companies engaged in software development.

Risk Level Icon

Risk Level

Medium: Choice of platform may not suit the applications being developed and deployed, resulting in wasted effort and investment.

30/60/90 Plan Icon

30/60/90 Plan

  • 30 days: Assess and baseline existing pipelines to evaluate preparedness.
  • 60 days: Build an appropriate CI/CD foundation, including socialization with teams.
  • 90 days: Train engineering, operations, and management staff.
Time to Value Icon

Time to Value

Initial efficiency improvements can be seen in three months, depending on business case, company size, and ability to accept new working practices.

What Is CI/CD?

Continuous integration/continuous delivery (CI/CD) is a methodology that enables optimization of software development stages through a set of agile processes and an end-to-end pipeline that enable a more frequent and efficient delivery of code changes (Figure 1).
Figure 1. The End-to-End CI/CD Pipeline

CI/CD enables enterprises to deliver innovation and business value quickly at speed and scale. From a business perspective, it offers an essential response to the demands of a rapidly evolving technological landscape.

At the practical level, CI/CD takes code from source control, builds it into a binary or artifact, then deploys the binary or artifact to a system (container, virtual machines, serverless, etc.). Some organizations may need to build code with just CI; automatically deploying it with code pushes using continuous delivery or deployment. CI/CD is also very useful for infrastructure automation.

What Are the Benefits of CI/CD?

From a business perspective, CI/CD allows an enterprise to respond to the demands of a rapidly evolving technological landscape, enables digital transformation, and drives faster and more efficient technology delivery. The ability to streamline development lifecycles, operate a dynamic distributed software development environment, and heighten team productivity yields a number of critical benefits. These can include:

  • A 50% or greater reduction in software deployment time.
  • Doubled, or even quadrupled, frequency of software deployment.
  • At least a 25% improvement in build times.
  • 10x or greater improvement in test run times.
  • Overall cost savings in the range of 40% to 70%.

One case study shows significantly faster software deployments after implementation of an automated CI/CD solution to orchestrate a mix of existing CI tools and streamline all the manual work. Another provider reports significant savings in time and money spent managing deployments through the implementation of an enterprise continuous delivery solution.

What Are the Scenarios of Use?

Adoption of CI/CD in production in the global cloud native community is very high because CI/CD is an effective methodology for automating application building, testing, and deployment.
Implementing CI/CD is critical for software development companies when current software and infrastructure cannot keep up faster and more “agile” development practices as evidenced by the following scenarios:

  • Organizations that want to accelerate software delivery, potentially as part of a move to cloud-based models.
  • Organizations wishing to turn existing, complex, and fragmented development pipelines into more consistent, unified, integrated, and efficient processes.
  • DevOps teams that need to replace unsuitable or outdated software development and deployment tools and practices.
  • Organizations looking to scale development, on-premises, cloud, or hybrid.
  • When existing automation scripts are increasingly challenging to maintain.

What Are the Alternatives?

The following alternatives can help in the implementation of CI/CD. Some may be less costly and easier to implement/adopt, but may not be as complete and integral, and could fail to resolve the issue of fragmented pipelines.

  • Use “low-code” solutions (e.g., Azure’s Deployment Center) or fully managed solutions (such as Google’s Cloud Build) or UI-based CI/CD (like Azure DevOps Classic with no YAML).
  • Use IDE solutions (Continuous Delivery Tools for Visual Studio, Azure Pipelines, GitHub Actions, etc.).
  • Use your current vendor’s tools/wizards (if you are using AWS Elastic Beanstalk for deploying and scaling web applications, use the tools they offer).
  • Use operational frameworks, such as GitOps, GitLab, etc.
  • Use open-source only alternatives, such as Jenkins.
  • Keep using existing tools (CI/CD or waterfall-based, even if they are outdated or unsuitable) and try to optimize their use.

What Are the Costs and Risks?

CI/CD costs vary by provider but are typically per deployment, for example with GitHub Actions. With some platforms, you’ll need to pay for the tool itself. With open-source solutions, like Jenkins, you only pay for server time. There are also training costs, as organizations adapt to engineering from the CI/CD perspective. CI/CD should allow software building quickly, repeatedly, and automatically.

Platform/provider and implementation/adoption related risks exist, as follows:

  • The largest risk of CI/CD for any organization is not mapping out the required process. If teams implement CI/CD to automate already flawed manual processes, CI/CD will make things worse.
  • The rapid pace of technological advancements makes many tools outdated quickly. Many CI/CD tools were designed for different times (today, there’s the cloud, more languages, etc.) Any change implemented by the provider/platform can disrupt its use; for example, if a platform drops support for Android or iOS.
  • Unnecessary problems/costs could be generated with CI/CD if priority isn’t given to activities related to CI/CD implementation, integration, and management to the business needs.
  • You will need to represent “replicability;” the ability to auto-generate the exact state of an entire software development practice at any point in the past. Replicability must include appropriate representation, replication, and management of required entities (artifacts, environments, etc.) in the pipeline as interdependent components.
  • Choosing an inadequate tool (for example, tooling specific for mobile apps vs. web-centric, or trying to maintain an outdated environment) can result in managing two or more tools, causing confusion, the need to set up training for multiple tools, and other overheads.

To respond to the risks, consider the following:

  • Measures should include quality on top of speed and efficiency. It doesn’t benefit anyone (company, DevOps team, and users) to move faster to market if other issues are created, such as flaky software and/or frequent failures during development and distribution.
  • Implement CI/CD as a complete process, from the beginning. This means considering it from end to end rather than “just” CI.
  • CI/CD needs to be considered in the context of delivering business results. It must integrate and align broader best practice elements, such as communication, collaboration, governance, risk, and so on.

30/60/90 Plan

GigaOm’s advice to any enterprise organization is to follow this order in the process of CI/CD implementation and adoption: standardize, automate, manage, extend, and expand. However, we also suggest this more specific 30/60/90 approach for an initial stage of implementation. Initial efficiency improvements can be seen in as little as 3 months, depending on factors like business case, company size, and state of CI/CD implementation.

30 Days: Assessment and Baseline
Validate the need for implementation of the technology, requirements, focal needs, evaluate tooling vendors, etc (MVP). Also identify what CI/CD will be used for. Mobile apps? Infrastructure code
deployments? Back-end and front-end applications?

Analyze table stakes (features and capabilities of solutions), key criteria (potential value to the organization), emerging technologies (impactful technologies emerging within the next 12 to 18
months), and evaluation metrics (scalability, interoperability, cost-effectiveness), to understand how solutions may impact and offer value to the enterprise.

60 Days: Foundation, Building, Planning
Evaluate the business preparedness for implementing and adopting CI/CD. Evaluate skills, code quality, CI/CD tools and practices already in use, resources (human, hardware, software) available and needed, etc. Also, define the core elements of the CI/CD platform, which will map onto the majority of development needs – for example locking down the code repository and adopting build and deployment tooling as standards.

From there, prepare a plan to:

  • Build an appropriate CI/CD foundation and tooling suitable for the core needs of development teams.
  • Ensure that security, pipeline quality, dependencies, and anything else that can cause tech debt in the future are taken care of.
  • Socialize the change and prepare development teams for acceptance, bringing in migration and adoption plans.
  • Develop skills, consulting, and mentoring to create/reinforce, encourage, reward, and manage a culture of iterative experimentation.

Finally, start measuring development performance baseline and improvements using DORA metrics.

90 Days: Plan Rollout in Audit Mode
Migrate your lowest-risk, highest-value development pipelines to the platform first, while setting out plans to migrate other pipelines. Perform an evaluation at the end of the 90 days to identify issues,
bottlenecks, recommendations, and define next steps.

Further Resources

All the arguments and recommendations included in this brief can be found in more detail in the following reports: