This documentation is for Octopus Deploy Version 3.13. View other versions

Deployment Processes

Last updated

Each project defines the actions you want Octopus to perform on your behalf. In Octopus terms this is called the deployment process. The deployment process is like a recipe. It defines the set of instructions that will be run repeatably each time the project is deployed.

Example: A simple deployment process

In the example shown below there are three steps that will be executed from top to bottom. The first is a manual intervention which executes on the Octopus Server pausing the deployment until someone intervenes and allow the deployment to continue. You may have noticed this step will only execute when targeting the Production environment - we'll talk more about that below. The remaining steps both deploy a package and execute custom scripts on all of the deployment targets with the role web-server.

Example: A rolling deployment

Let's consider a more complex example like the one shown below. In this example we have configured Octopus to deploy a web application across one or more servers in a web farm behind a load balancer. This process has a single step and three actions which form a rolling deployment.

In most simple cases each step will have a single action, and as a convenience these are combined together in the user interface. This is why we talk mostly about steps, and sometimes the word step and action are used interchangeably.

Steps and actions

To fully leverage the power of Octopus deployments it helps to understand the difference between steps and actions, and how they are treated.

Each deployment process consists of a series of steps, where each step can have one or more actions. Each action defines what you want Octopus to do on your behalf, and each step defines the execution planandcontext of its action(s).

Let's look at the Trading Website Rolling step from our earlier example. It is configured to execute the actions across all deployment targets with the web-server role (this is the context), one deployment target at a time due to the window size of 1 (this is the execution plan). Learn more about rolling deployments.

This distinction between steps and actions has proven to be a really simple way to enable complex scenarios like rolling deployments, even though the distinction causes some confusion for our customers.

How Octopus executes your deployment process

By default, the list of steps in a deployment process are run sequentially from top-to-bottom, one after another.

A step that is configured to execute across multiple deployment targets will execute across all of those deployment targets in parallel.

You can define steps with multiple actions and apply a window size (like our earlier example) where the same step will execute across a limited number of deployment targets in parallel.

For more information, see the section on rolling deployments.


Steps and actions can also have conditions. You can restrict a step so that it only runs when deploying to specific environments (e.g., an Email step that only runs on production deployments).

If you have created some channels, you can also specify whether a step runs only when deploying a release through specific channels (e.g., a Script step that only runs for deployments through certain channels to configure extra telemetry). This will only appear if you have created one or more non-default channels.

You can also specify whether a step runs only when previous steps are successful (default), when a previous step fails, or always.

Working with the Octopus API

Octopus Deploy is built API-first, which means everything you can do through the Octopus UI can be done with the API. In the API we model the deployment process the same way, starting at the Project:

  • Project
  • Deployment Process
  • Steps
  • Actions

We have provided lots of helpful functions for building your deployment process in the .NET SDK, or you can use the raw HTTP API if that suits your needs better.

Learn about using the Octopus REST API.

Record the HTTP requests made by the Octopus UI to see how we build your deployment processes using the Octopus API. You can do this in the Chrome developer tools, or using a tool like Fiddler.