Event-based triggering—Pipelines will need to be triggered and executed in response to various events—for example, when pull requests are opened or merged.

Periodic triggering—Regular scheduled execution of pipelines can help reveal issues such as flaky tests and can be used to support release strategies such as nightly releasing.

Config as code (aka build as code)—Storing your CD pipelines in version control is crucial; the same best practices you apply to your business logic should be applied to all the data that makes up your software.

Run as a service—Without a consistent service executing your CD pipelines, it is impossible to ensure that your software is built consistently, and auditing is nearly impossible.

Ephemeral environments—Starting from a clean environment every time you build an artifact ensures that you get the same results every time. This is often accomplished using one-time-use VMs and containers for execution.

Pipelines—Graph-based orchestrations of tasks with control-flow features specific to CD use cases.

Tasks—Units of logic that are ideally highly cohesive, loosely coupled, well factored, and reusable.

Inputs and outputs—To reuse tasks and pipelines, it must be possible to provide them with inputs that support customizing their behavior. Outputs make it possible to plug tasks and pipelines together so their behavior can vary based on the behavior of other tasks and pipelines.

Conditional execution—Being able to control at runtime which parts of a pipeline execute makes it possible to write very flexible pipelines that can be more easily reused.

Finally behavior—CD pipelines often contain behavior that must happen, even when other parts of the pipeline fail. Cleaning up environments and sending notifications such as instant messages are examples.

Parallel execution—Running tasks in a pipeline that have no dependencies on one another can reduce overall pipeline execution time.

Matrix-based execution—An extended version of parallel execution, this allows tasks to be automatically run multiple times in parallel for combinations of input, supporting complex testing use cases such as sharding.

Pipelines using pipelines—In addition to making tasks reusable, it is often useful to define reusable pipelines that combine tasks, linking their inputs and outputs, so these pipelines can be reused in multiple scenarios.

Triggering is supported through the companion project Argo Events, which supports multiple event sources (including version control systems such as GitHub, and cloud integrations).

You must host and run Argo yourself; it can be used to provide a CD service within an organization.

Containers are the basic unit of execution, providing ephemeral environments.

Workflows (corresponding to pipelines in this book) execute Workflow templates.

Workflow templates (reusable workflows) contain steps and/or directed acyclic graphs.

Workflow templates are reusable, and they take input parameters and produce results via artifacts. Steps can declare inputs and outputs (which can be parameters or artifacts).

Conditional execution is supported with a when syntax.

Matrix-style execution is supported via the loops feature.

Pipelines-using-pipelines behavior can be achieved by workflow templates calling other workflow templates.

Integrates directly with version control systems and can trigger execution on events from those systems, including GitHub and Bitbucket, and workflows can be scheduled to execute periodically.

CircleCI was built around the idea of config as code and expects to find CD configuration for your project in a folder called .circleci in the root of your repo.

It can be used via the public hosted service or can be run as a server in a self-hosted mode.

Build environments (called executors) are ephemeral and can be backed by VMs or containers; it is possible to reuse VMs across jobs if desired (which would mean the execution environment is intentionally not ephemeral); containers are never reused.

Pipelines (corresponding to pipelines in this book) contain workflows as well as triggering information.

Workflows (also roughly corresponding to pipelines in this book) orchestrate jobs.

Jobs (corresponding to tasks in this book) contain sequential steps.

Commands can be reused within steps in jobs.

Orbs (also roughly corresponding to tasks in this book but also going a bit beyond it) define reusable jobs, commands, and executors.

Parameters can be declared by jobs, commands, and executors. Using outputs between jobs is accomplished by persisting data to workspaces or by using the BASH_ENV environment variable.

Steps within a job can be executed conditionally using the when and unless keywords.

Finally behavior at the step level is supported by specifying the condition always.

Jobs within a workflow can run concurrently or sequentially. To run jobs sequentially, use the requires keyword to declare dependencies between jobs. Steps in a job can be made to run in parallel with the parallelism keyword.

The matrix keyword allows for jobs to be executed multiple times, once for each unique combination of the matrixed values.

Triggering on many different activity types for each repository, from scheduled cron events, to pull request updates, to interaction with GitHub issues.

It not only supports using a config-as code approach, but that is the only way to set up GitHub workflows. The definitions of these workflows live in the repository that triggers them, and it is possible to refer to workflows and actions that live in other repositories.

When using public GitHub, the CD system is hosted and run by GitHub itself. If you use GitHub Enterprise in self-hosted mode, you are responsible for configuring and running the platform that executes the actions.

Each GitHub Actions job is run in an ephemeral environment that is created to run the job and is torn down afterward. The job can be run as an entire VM, or a container within a VM.

Workflows (corresponding to pipelines in this book), orchestrate jobs.

Jobs (corresponding to tasks in this book) contain sequentially executed steps.

Actions (also corresponding to tasks) are reusable jobs.

Jobs within workflows can declare and emit outputs that can be used by other jobs within the same workflow as inputs. Reusable workflows can define inputs and outputs.

Jobs within GitHub workflows can use the if statement to define conditions under which they will execute.

Finally behavior is also supported using this syntax, by specifying if always() as a condition for a job to indicate it should always run.

By default, all jobs in a workflow will execute in parallel, unless the needs syntax is used to indicate that one job should run after another job.

The matrix keyword allows for jobs to be executed multiple times, once for each unique combination of the matrixed values.

Workflows can be defined as reusable workflows that can be used by other workflows.

Triggered execution is supported based on events from integrated version control systems including GitHub, GitLab, and Bitbucket, as well as webhook triggering via GCP’s Pub/Sub and scheduled periodic triggering.

GCB triggering can be configured to read the build definition from the triggering repository, supporting config as code.

GCB is provided as a service hosted and run by Google as part of Google Cloud Platform (GCP).

Steps in GCB builds are executed as ephemeral containers that are run on VMs.

Builds are made up of steps. Builds correspond to the tasks concept in this book, and somewhat to the pipelines concept as well (since steps can be executed as graphs, with steps being executed sequentially or in parallel).

Each step is executed as a container.

Builds can use inputs provided at runtime via the user-defined substitutions feature.

By default, steps in a build execute sequentially; the waitFor keyword can be used to explicitly declare the order in which the steps are meant to complete and can be used to create graphs where some steps are executed in parallel.

Jenkins Pipeline can be configured to trigger on a variety of events, including the pollSCM trigger, which can be used to poll various version control systems (such as GitHub), and cron triggers, which allow you to schedule execution.

Jenkins pipelines are defined in Jenkinsfiles, which can be stored in version control and read directly by Jenkins, enabling config as code for the pipeline definitions.

You must host and run Jenkins yourself. It can be used to provide a CD service within an organization.

Various kinds of execution environments are supported, including containers that can be used as ephemeral environments.

Pipelines (corresponding to pipelines in this book) are made of stages.

Stages (corresponding to tasks in this book), are made of steps.

Pipelines can use the keyword parameters to declare inputs they require.

The when directive can be used to execute stages conditionally.

Finally behavior is supported by the post section of the pipeline, which indicates steps to run after the completion of the rest of the stages (even if those stages fail).

Stages in a pipeline can be made to run in parallel by declaring them within nested parallel blocks.

The matrix keyword allows for stages to be executed multiple times, once for each unique combination of the declared axes.

Pipelines can use other pipelines that are declared in Jenkins shared libraries.

Pipelines can be either declarative or completely scripted using the programming language Groovy. Scripted pipelines have complete flexibility in supported conditional execution and finally behavior (via try/catch).

Triggering on any arbitrary event is enabled via the Tekton Triggers project, which supports any source of events and has built-in support for GitHub, GitLab, and Bitbucket triggering features.

It can be run as a service inside of a Kubernetes cluster, and used directly or used as a platform on which to build another CD service.

The basic unit of execution in Tekton is a container, so execution environments are completely ephemeral.

Pipelines (corresponding to pipelines in this book) orchestrate tasks.

Tasks (corresponding to tasks in this book) sequentially execute steps.

Each step is executed as a container.

Pipelines and tasks can both define inputs (parameters) and outputs (results).

Conditional execution of tasks within a pipeline is supported via the when syntax.

Finally behavior in pipelines is supported by a finally section in the pipeline that defines tasks that must always execute.

By default, any tasks in a pipeline will execute in parallel, unless a dependency has been expressed between them. Dependencies are expressed by a task declaring that it needs a result from another task (and so it must run after that task) or by using the runAfter keyword to express ordering.

The matrix keyword within a pipeline can be used to execute a task for all unique combinations of the specified array values in the matrix declaration.

Out-of-the-box support for config as code by referencing pipelines and tasks in version control (and other locations, such as in OCI registries) directly.

Pipelines reusing other pipelines: in the same way that pipelines orchestrate tasks, they could also refer to other pipelines.