Environments

Last updated

Octopus Deploy organizes your infrastructure, that is the deployment targets you deploy software to (whether on-premises servers or cloud services), into environments. Typical examples of environments are Test, Stage, and Production.

Organizing your deployment targets into environments lets you define your deployment processes (no matter how many targets are involved) and have Octopus deploy the right versions of your software to the right environments at the right time.

Managing Environments

Environments and the machines inside them can be managed from Infrastructure ➜ Environments within the Octopus Web Portal.

Environments can be added using the Add environment button.

Adding Machines to Environments

Machines can be added to environments in different ways, depending on how they will communicate with the Octopus Deploy Server.

Environment Ordering

Environments are shown in order, and can be reordered using the Reorder link in the overflow menu at the top right-hand corner of the page.

The order that environments are shown on the Environments tab also affects:

  • The order that they are shown in the Dashboard
  • The order that they are listed in when choosing which environment to deploy a release to

It's a good idea to put your least production-like environments first, and the most production-like environments last.

Guided Failures

Guided failure mode can be enabled on an environment by default. This is useful for critical environments that are usually deployed to manually (for example, staging and production-like environments), though you may want to disable this feature for environments which are deployed to automatically such as smoke testing environments.

Guided failure mode is an option when editing an environment:

(Note that this option only sets it by default: for individual deployments it can be overridden)

Associating Projects with Environments

By default, a project can be deployed to any environment. You can limit which projects can be deployed to which environment using Lifecycles. This is useful if you have one set of environments for projects developed by one team, and another set of environments for projects developed by another team.

Environment Permissions

You can control who has access to view or edit environments, as well as who has access to deploy to environments, by assigning users to Teams and assigning roles to those teams. For more information, see the section on managing users and teams.

In This Section

The rest of this section covers these topics in some more detail, and explains how to implement them.