Part 2, Continuous Delivery – InApps is an article under the topic Devops Many of you are most interested in today !! Today, let’s learn Part 2, Continuous Delivery – InApps in today’s post !

Read more about Part 2, Continuous Delivery – InApps at Wikipedia

You can find content about Part 2, Continuous Delivery – InApps from the Wikipedia website

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.

Read More:   Update Confluent ‘Proactive Support’ Aims to Speed Resolution of Kafka Streaming Data Issues

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.

Read More:   Update MapR Platform Offers Persistent Data Access for Containerized Applications

Lead image by Karthik Garikapati via Unsplash.


Rate this post
As a Senior Tech Enthusiast, I bring a decade of experience to the realm of tech writing, blending deep industry knowledge with a passion for storytelling. With expertise in software development to emerging tech trends like AI and IoT—my articles not only inform but also inspire. My journey in tech writing has been marked by a commitment to accuracy, clarity, and engaging storytelling, making me a trusted voice in the tech community.

Let’s create the next big thing together!

Coming together is a beginning. Keeping together is progress. Working together is success.

Let’s talk

Get a custom Proposal

Please fill in your information and your need to get a suitable solution.

    You need to enter your email to download


      Success. Downloading...