Last week, we announced the General Availability for Shippable Server. With the announcement, we also articulated how we see DevOps: both as it is today and where the next wave is headed. For more context on our vision for the next wave, aka DevOps Assembly Lines, you can read our whitepaper.
However, before discussing evolution of DevOps, we found that most folks we spoke to were confused about the plethora of terms that are thrown around. A few are Continuous integration, Continuous Delivery, Continuous Deployment, CI/CD, Application Release Automation (ARA), and Pipelines. Tool vendors seem to use these terms interchangeably, but they each have distinct meanings that you should understand so you can also figure out which part of the DevOps puzzle is addressed by the vendor.
This blog provides definitions for each term along with some examples. We are working on a detailed whitepaper that will also include an opinionated list of tools available for each term below.
1. Continuous Integration (CI)
Continuous integration is a software development activity that requires developers to integrate all source code into a shared repository several times a day. Each commit is then verified by an automated build, allowing teams to detect defects early in the cycle. The result of a CI step is typically a unit-tested and consistent codebase.
A basic CI workflow is shown below:
In recent times, the definition of CI has been expanded to include additional steps, causing frequent confusion as to where CI really ends.
2. Application Release Automation(ARA)
Application Release Automation (ARA) helps take an application release from source control, through multiple pipelines like build, CI , package, deployment to Dev environment, deployment to Staging environment, and ultimately deployment to Production environment, with a linear workflow. You can configure manual or automated steps or gates between each pipeline.
A typical ARA pipeline is shown below:
ARA pipelines do not account for peripheral tasks like infrastructure provisioning, managing machines images, security patching etc.
3. Continuous Deployment (CD)
Continuous Deployment (CD) is achieved when you can do zero-touch deployments from source control to production for every commit. This should be the goal for every application and offers the fastest way to release software updates to your customers.
While some argue that you can do CD with ARA tools, this is rarely the case. Continuous deployment requires a lot of discipline at each stage of your software delivery workflow, and also requires automation of tasks like infrastructure provisioning and security patching. If every task in the DevOps workflow isn't automated, you will run into many scenarios where you cannot achieve CD.
4. Continuous Delivery (the other CD)
Continuous Delivery is a philosophy which dictates that the HEAD of your application codebase (e.g. latest commit to master branch), or the most recent immutable version of the software package, is always deployable to production. If you automate CI, deployment to successive test environments, and automatically kick off the relevant test suites for each environment to verify that no regressions were introduced and the new functionality works as expected, you have achieved Continuous Delivery.
Continuous Delivery stops just one step before Continuous Deployment, since you need to ensure that each code change is deployable, even if you don't choose to deploy it. Therefore, to achieve Continuous Delivery, you need to automate every task in the DevOps workflow.
This term is commonly used by CI vendors that are trying to pretend to also do CD. In this context, what it really means is that after your code is built and unit tested, it can be packaged and pushed to any environment you desire with a few extra steps in your configuration. However, this is not sufficient to achieve Continuous Delivery or Deployment unless you have a very simple non-commercial application that can be deployed to production with no steps between unit testing and deployment.
The term 'Pipeline' is also becoming ubiquitous in the last year. Every vendor calls its solution a pipeline, which can get confusing since the word "pipeline" suggests something that is end-to-end. Since this is rarely true, we've come up with a more accurate description for this context:
A Pipeline is a point-to-point set of instructions or activities that are executed in sequence and achieve a singular goal, such as deploying a commit to an endpoint, or pushing a Docker image to a hub, or provisioning infrastructure for an environment.
The reason this gets confusing is, every vendor can call its solution a pipeline since the singular goal of a pipeline can be literally anything. A CI pipeline can consist of build-test-package, or build-test-package-deployTest, or build-test-package-pushToArtifactory. An Infrastructure Provisioning pipeline can consist of provisioning or updating environments every time the provisioning scripts change.
So what are Assembly Lines?
After looking at all the terms to describe the value Shippable brings to the table, it was obvious that we needed to go back to the basics and find our own way. What Shippable gives you is the ability to easily interconnect your numerous pipelines into a streamlined workflow for Continuous Delivery or Deployment. This means that your CI, Infrastructure provisioning, security patching, release mgmt, and deployment pipelines are all connected into one stateful workflow that enables pipelines to talk to each other and exchange whatever information is neccesary to ship your application.
The easiest way to think about it is to think of the car manufacturing analogy. We initially had highly custom, handcrated cars, comparable to achieving each DevOps activity manually. Then came automation for individual parts of the car, comparable to automating pipelines that perform specific tasks. The next evolution was Assembly Lines, which could take the parts and assemble them into a car with no manual intervention. Shippable gives you exactly that in the DevOps world: the ability to take these diverse pipelines and connect them into DevOps Assembly Lines.
As an example, here is a high level view of an Assembly Line to ship one application or microservice. Each individual box is a pipeline and the color indicates which team is responsible for that pipeline.
For more on Assembly Lines, download our whitepaper: