DevOps Consulting: Continuous Delivery

If you’re working with software, you’ve probably come across the terms “Continuous Delivery,” “Pipeline Runners,” and “Infrastructure as Code (IaC).” Or perhaps you’re already benefiting from automated deployments in your organization and want to learn more about the inner workings of these magic boxes.

Continue reading to learn more about Continuous Delivery and its role in the software delivery cycle!

On this page:

• Why is Continuous Delivery Needed?
• What is Continuous Delivery?
• How does Continuous Delivery Work?
• What options are available for Continuous Delivery?
• How much does Continuous Delivery cost?
• How do I get started with Continuous Delivery?
• Next Steps
• DevOps Consulting Services

Skip the details—Contact Bitovi DevOps Consulting today to book a free consultation.

Why is Continuous Delivery Needed?

Continuous Delivery is needed to manage operations and deployments efficiently.

Without continuous delivery, operators would need to either manually create and configure compute space for deployments or manually run software configuration to perform a change (e.g., run a script like deploy-o-matic production). Additionally, developer work might be on hold until a deployed environment is available and up-to-date.

With continuous delivery, developers can continue forward quickly and easily because changes checked into their code automatically result in an up-to-date deployed environment.

Continuous Delivery decreases development time by enabling rapid development lifecycles. Rapid development is best described as the automated moving of developer code, such as bug fixes or new features, from a development environment to a hosted compute that is usable for end users or tests. For bugs in particular, rapid development lifecycles translate to a lower mean time to recovery (MTTR) for your services.

MTTR: Mean time to recovery

MTTR (mean time to recovery or mean time to restore) is the average time it takes to recover from a product or system failure. This includes the full time of the outage—from the time the system or product fails to the time that it becomes fully operational again.

- Atlassian

What is Continuous Delivery?

To illustrate what it means to deliver continuously, let's first define a deployment.

Deployment

Deployment is defined as a process that results in an app or service running in some form of compute.

The deployment process will vary depending on the size and complexity of the project. Still, the manual process often involves manual scripts (and authentication) on a developer’s computer or terminal access to the running host to log in and “pull” code or artifacts to initialize.

Continuous Delivery

To then automate the deployment, the scripts that were executed manually are instead referenced from Pipeline Runner configuration, which is often checked into the same repo as the scripts.

Based on events defined in the pipeline runner configuration (such as a commit to the main branch), the pipeline runner will start a pipeline to perform the deployment often defined in the deployment configuration. Continuous delivery often involves a manual approval step, whereas continuous deployment requires no such intervention.

Continuous Deployment

Like continuous delivery, continuous deployment is an automated process to ship code to deployed environments. One key difference, however, is that continuous deployment requires no manual intervention for environment promotion (moving changes from staging to prod, for example). Continuous deployment will involve things like canary deployments to automatically check the necessary conditions for full roll-out.

Where Does Continuous Delivery Deploy?

Deployable artifacts will be deployed to some form of compute. The compute often takes one of the following forms:

• Static files on a CDN
• Virtual Machine
• Serverless provider
• Container orchestrators like Kubernetes or Elastic Container Service

Deployable artifacts will need some location to be deployed to, and there are several ways to get access to compute:

• Use a SaaS hosting provider like Heroku (which can often have less functionality and/or more cost than a direct cloud provider approach)
• Cloud provider UI (though this is generally discouraged in favor of IaC for apps that need to scale)
• Infrastructure-as-Code and a deployment repo (like a BitOps Operations Repo)

How Does Continuous Delivery Work?

The underlying mechanism for continuous delivery are:

• Pipeline runners & pipeline runner config
• Infrastructure-as-Code
• Approvals
• Versioning strategies

Pipeline Runners & Pipeline Runner Config

For continuous delivery to be continuous, something needs to act on your code when actionable things change. Pipeline runners are essentially engines that automatically perform tasks, or run pipelines, whenever code or configurations change.

Infrastructure-as-Code

Infrastructure-as-code essentially defines the state of the infrastructure in code or configuration (ideally checked-in). You can think of it as a versioned blueprint of your infrastructure.

Defining infrastructure-as-code for your deployments will allow your efforts to scale up much more efficiently than managing resources through clicks (i.e., “ClickOps”).

Hooking it All Together

Once you have a pipeline runner and infrastructure-as-code, you will need to craft a pipeline configuration file that executes the appropriate infrastructure-as-code CLI tool against the configuration when desired changes occur.

What Options Are Available for Continuous Delivery?

Cloud engineering and DevOps often require careful research and selection of tooling, and selecting the right tools for your continuous delivery pipeline is no exception, as there are many options to choose from.

Generic Pipeline Runners

To start, you’ll need a pipeline runner that can connect to your repo. Most modern pipeline runners, such as GitHub Actions or GitLab Pipelines, provide some form of in-repo configuration.

Deployment-Specific Pipeline Runners

Some pipeline runners are built specifically for deployment management. Some deployment-specific pipeline runners are “push” based and send the configuration to the desired compute, such as Harness or Spinnaker, while others are “pull” based and fetch config from the desired compute, such as ArgoCD or FluxCD.

Infrastructure-as-Code

For infrastructure-as-code, there are many options available. Terraform, for example, is a powerful tool for defining cloud provider resources like virtual machines, security group, or even Kubernetes clusters. Ansible, on the other hand, is a good tool for installing necessary apps and services onto an existing virtual machine, and Helm is the go-to package manager for Kubernetes deployments. Other options include AWS CloudFormation, Packer, IstioCTL, Spinnaker Halyard, Pulumi, etc.

How Much Does Continuous Delivery Cost?

The cost for continuous delivery itself can vary depending on the size and complexity of your project and how often things are being delivered, but to help break it down, here are a few things to keep in mind:

• How often do you need to deploy?
• How many environments do you need?
• Do you have any dependent services?
• Are you maintaining infrastructure-as-code?
• Are you using a SaaS product for some/all of your deployments?

For simple applications, you could easily set up a GitHub Action to deploy to an AWS virtual machine with the Deploy Docker to AWS (EC2) action. In that case, your costs, in addition to the small amount of time required to set up the in-repo pipeline configuration, are limited to your pipeline runner cost and your cloud provider cost (i.e., running and routing traffic to the instance).

On the other end of the spectrum, perhaps you have account management and global tooling to provide via a Platform Engineering team. In that case, you’d want people available who can effectively manage the underlying infrastructure tooling, and you’d have to calculate that effort with things like the compute and resources for all the tooling hosted internally and the cost for any enterprise licenses or SaaS deployment mechanisms.

In many cases, there will be an initial spike in your team's effort. Still, the effort required to maintain the continuous delivery pipeline should diminish substantially and quickly transition to maintenance mode.

Getting Started with Continuous Delivery

A great place to get started with Continuous Delivery if you have an app/service or have one in mind is with GitHub Actions as a pipeline runner and AWS as a cloud provider. From there, you can easily set up a simple deployment pipeline to iterate.

Here’s a quick-start video to show how simple it is:

Other ways to get started with Continuous Delivery:

• Explore deployment tooling that is appropriate for your team and project structure, including pipeline runners, Infrastructure-as-Code patterns & tools, hosting solutions, SaaS solutions like Harness.io, community projects like BitOps, automation catalog availability like the GitHub Actions Marketplace or GitLab Auto DevOps.

• Start tracking your mean time to recovery (and other similar pipeline metrics), which will help you uncover bottlenecks in your CI/CD pipeline.

• Define your deployment strategy with considerations for current challenges and future growth. Are your services independently deployable? Does automated cross-service testing require deployed environments? Will you get enough value out of PR environments to justify their cost of them? How many environments and approvals do you have before your code reaches end users? How should changes be promoted from lower environments like dev or staging to higher environments like production?

Next Steps

You should now have a decent idea about the role Continuous Delivery plays in automated software delivery, including why it’s needed, what it is, how it works, some options that are available to you, roughly how much it costs, and how to get started.

Having a high-level understanding is only the tip of the iceberg for Continuous Delivery, however, and there are many features, strategies, and patterns that you and your teams can leverage to take full advantage of Continuous Delivery and enhance your Software Delivery Automation and DevOps approach.

DevOps Consulting Services

Regardless of where you are on your DevOps maturity journey, you should consider leveraging the expertise of 3rd parties or vendors, like Bitovi DevOps Consulting. You can easily bring in DevOps and operations expertise to your projects to bootstrap your infrastructure, automations, DevOps culture, and maturity plan.