Why CI/CD matters

devops ci-cd

In this age of cloud and users expecting instant results at all times, companies need to be capable of responding to changes with extremely quick turnarounds. This is where Continuous Integration and Continuous Delivery/Deployment (CI/CD) comes into play. It helps businesses deliver value faster and better for their users.

In this post, I’ll explain why CI/CD is essential for companies and developers. First, I’ll dive into what CI/CD means. Then, I’ll analyze its benefits, followed by a review of essential practices. Finally, I’ll conclude with some extra resources in case you want to dig deeper.

Definitions

Let’s start by defining Continuous Integration (CI) and Continuous Delivery/Deployment (CD).

Continuous Integration

Instead of coming with my own definition, let’s look at this widely used definition by Martin Fowler:

Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily - leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible.

Martin Fowler, URL: https://martinfowler.com/articles/continuousIntegration.html

Continuous Integration represents a paradigm shift in the way we build software. Without CI, your software is broken until somebody proves that it work. To fully benefit teams, a CI pipeline should be run on every commit on any branch to allow for faster verification of changes and feedback.

Continuous Delivery/Deployment

Similar to what I did when explaining CI, let’s use the following definitions by Jez Humble and Martin Fowler to define Continuous Delivery and Continuous Deployment:

Continuous Delivery is the ability to get changes of all types—including new features, configuration changes, bug fixes and experiments—into production, or into the hands of users, safely and quickly in a sustainable way.

Jez Humble, URL: https://continuousdelivery.com

Continuous Deployment means that every change goes through the pipeline and automatically gets put into production.

Martin Fowler, URL: https://www.martinfowler.com/bliki/ContinuousDelivery.html

Now that know what each concept means, let’s analyze how they fit together.

CI + CD

Looking from the perspective of software development lifecycle, a CI process automates the coding + building + testing stages; while a CD process extends CI to also cover releases/packaging (if doing Continuous Delivery), or releases/packaging + deployments (if doing Continuous Deployment).

ci_cd_lifecycle

Now that we have covered these concepts, let’s evaluate what the main benefits are of applying these practices.

Benefits

Although I think that implementing a CI/CD process is the right action to take in the majority of scenarios; many teams and developers need more than that to jump into it. In order to provide more supporting information, let’s discuss what their main benefits are.

Continuous Integration

  • Reduced risk: By running tests automatically on every commit, defects are easier to detect and fixed sooner . Also, it facilitates measuring the health of the software over time and reduce assumptions since we are continuously running on clean environments.
  • Reduce repetitive manual processes: As part of a CI pipeline, the different stages are executed the same every time automatically. This helps teams focus in higher-value work since manual, repetitive work is automated away.
  • Generate deployable software: By far, this is the most tangible benefit for external parties, such as clients and users. When there are problems, these are reported quickly and the team can fixed right away since they have the context about the recent changes. Consequently, the time the code is not in a deployable state trends towards zero.
  • Enable better project visibility: It provides just-in-time information on recent build status and quality metrics (e.g: defect rates, number of flaky tests, time to completion). Also, it facilitates noticing trends in build success or failures, overall quality and other related project information
  • Greater product confidence: Makes it easier to understand the impact of code changes since tests automatically verify that the expected behavior is being met. In addition, it encourages a single-source point from which to generate all software assets, which in turns increases the confidence about deploying said artifacts.

Continuous Delivery/Deployment

  • Low risk releases: By making deployments painless and repeatable, these pipelines can be executed at any time, on demand. Pushing a bit further, it is possible to achieve zero-downtime during deploys that are undetectable to users.
  • Faster time to market: By incorporating traditional phases of the software delivery lifecycle, such as integration and regression testing, into developers' daily work, we effectively remove them as bottlenecks. In addition, this leads to significant reduction in the amount rework that is common in staged-based approach. As a result, developers have increased productivity and more time towards feature development.
  • Higher quality: Automating regression detection frees people to explore user research and focus on higher level testing (such as: exploratory, usability, performance and security). As part of a deployment pipeline, then this activities can be performed continuously, which ensures that quality is built-in to products and services.
  • Lower costs: Automation of environments and build, test and deploys processes reduces significantly the costs of making and delivering any individual change, since the fixed costs associated with a release/deployment process are eliminated (e.g: operations time to prepare and deploy server, lack of context when deployments happen long after features has been implemented)
  • Better products: By encouraging the release of smaller changes, it enables the possibility of testing ideas with users using techniques such as A/B testing. Later, the resulting data can be integrated back into the product to guide decisions about these features.
  • Happier teams: More frequent deployments allow teams engage more actively with users, learn which ideas work and which don’t. Also, it is easier for teams to verify and evaluate the outcomes and impact of their work.

To reap the full rewards, you need to go all the way in both areas. You shouldn’t just commit to a CI process and then having a manual process for releases and deployments. You lose most of the leverage you got from doing CI, since your manual deployments are likely to be missing the appropriate context for developers to figure out new issues as they happen.

Practices

A CI/CD pipeline relies on certain prerequisites being already in place for a successful implementation.

Continuous Integration

  • Maintain a single central repository
  • Automate the Build
  • Every commit in the main branch should trigger a build process
  • Fix broken builds immediately
  • Keep the build fast
  • Always Be Prepared to Revert to the Previous Revision
  • Time-Box Fixing before Reverting
  • Don’t Comment Out Failing Tests
  • Everyone can see what is happening

Continuous Delivery/Deployment

  • Software is deployable throughout its lifecycle
  • The team prioritizes keeping the software deployable over working on new features
  • Fast, automated feedback on the readiness of the systems anytime a new change is made
  • You can perform push-button deployments of any version of the software to any environment on demand

Resources

If you want to dive deeper and learn more about CI/CD practices, I recommend you the following resources, which I used as the basis for this post

Disclaimer: The opinions expressed herein are my own personal opinions and do not represent my employer’s view in any way.