CI/CD / DevOps / Sponsored / Contributed

CI vs. CD Explained by Emoji: Part 2, Continuous Delivery

3 Jun 2021 12:00pm, by

Margaret Francis
Margaret is president and chief operating officer of Armory, and a seed investor in minority and women-led businesses. Previously she was senior vice president for product and general manager of Heroku. She holds a bachelor's degree from Yale University and an MFA from SFAI. For fun, she reads a lot of science fiction and plays with her kids.

Continuous integration/continuous delivery (CI/CD) can be confusing. We thought it would be fun to explain the subject through emojis and a pizza analogy. If you want to catch up with the series, read Part 1 explaining what is involved in CI/CD and the initial continuous integration (CI) process.

For Part 2, we’re stretching our CI/CD Pizza (Git)Hut Company analogy as far as it will go and covering continuous delivery (or CD) and how it differs from continuous deployment. Continuous delivery (CD) extends continuous integration from the stage where our stable build 📃 or single artifact has been built and centrally stored, right through to being ready for production. In our analogy, it takes developed pizza recipes, cooks 🥣 them based on the central recipe and tests the resulting pizza in many different ways to make sure that it’s ready for delivery and ready to be eaten by customers.

What is Continuous Delivery?

CD essentially treats every code commit 🍅🧀 from a developer 👩🏿‍🍳 as a release candidate 🍕 — or, in our pizza analogy, as a potential “new pizza” that can be “eaten.” It’s sent along automated deployment pipelines to a staging environment unless it is proven defective. Once our “release candidate pizza” passes testing 🥄, it sits in staging, at the end of the conveyor belt, neatly boxed up, waiting for the final thumbs-up, before being picked up for delivery 🛵 and into production.

Continuous Delivery

Spinnaker, developed initially at Netflix, is an excellent example of CD, as it can connect into the central repository stage in CI through tools such as Jenkins 👨. Spinnaker wasn’t designed as a build tool for artifacts. Instead, Spinnaker was designed with a CD focus for multicloud ☁️☁️ and can handle pipelines with multiple deployment approaches and easy rollbacks ⏪. Using existing CI tools like Jenkins, Spinnaker can trigger a webhook in Git, for example, to kickstart a staging pipeline. The staging phase can include many different tests, such as canary analysis to look for key metrics such as 5XX server errors and load testing. It also allows for customizing when manual judgments are required, for example, for test clean-ups and, of course, whether to deploy code into production. Throughout the process, it will generate commentary on the open ticket.

Where Does Continuous Deployment Fit? 

You may find continuous deployment mentioned alongside CI/CD. It is essentially the same as continuous delivery, except it is a pipeline that is entirely automated 🤖 from start to finish, including the final decision to sling that pizza out the door. As you would expect, continuous deployment isn’t suitable for all use cases unless you trust that your AI won’t give you food poisoning — or, worse, approve a salad pizza and deliver that to a customer. However, it can free up a developer or operator’s time for other things when implemented correctly.

Continuous Deployment

Once the release candidate is thoroughly tested via an automated process, continuous deployment delivers it to the customer.

A Perfect Pizza Needs the Right Oven

So you can see that when CI and CD are combined, it enables ideas to go from inception to production in a much shorter time frame. In some cases, minor releases can happen a few times a day, when it took six months or a year with the waterfall methodology.

Ultimately, you will want to automate code from commit to production-ready. Whether that ends with a manual or automated approval will depend on the software. When deciding the best approach, you will need to consider several different things, such as avoiding scripts that don’t scale, choosing a solution with tool and infrastructure integrations, and avoiding excessive plugin management. CI/CD only works if code is tested for consistency and quality early in the process and throughout the various pipelines you establish.

CI/CD accelerates the time to market by removing as many human interventions as possible. It centralizes control, provides visibility into performance, and accurately monitors and flags issues. If you want to make pizzas that are better than mamma used to make, CI/CD can help you get there. If you’d like to learn more about the benefits of Armory’s continuous delivery platform, check out our 101 guide.

Lead image by Karthik Garikapati via Unsplash.

A newsletter digest of the week’s most important stories & analyses.