The Channels Walkthrough covers all of these topics as well as how to implement the most common scenarios that will benefit from Channels.
Channels in Octopus Deploy will help you if you want to:
- Manage multiple active versions of the same project. For example, maintaining patch/hotfix releases for v1 whilst starting work on v2.
- Change your deployment process without creating a barrier for production releases. For example, adding a new step to your process, or modifying an existing step.
- Deploy a hot-fix directly to Production where you would normal promote each release through a series of Environments.
- Provide your customers with access to early builds of your project.
- Automatically deploy feature-branch builds to a test environment, sometimes called a Phoenix environment. For example, as soon as a developer commits code to a feature branch, you want that version of the project to be deployed into a sandbox test environment.
- You use a branching strategy in your source code repository. For example, you might be using GitFlow or another source code branching strategy.
Each Release you create in Octopus Deploy is placed into a Channel, and Releases in each Channel can be treated differently. For each Channel you can define:
- Which Lifecycle to use for promoting Releases: for example, feature releases may be promoted through the testing environments, while hot-fix releases may go directly to production.
- Which Deployment Process to use when deploying Releases: for example, steps can be enabled for specific channels.
- Which Variables to use: Variables can be scoped to channels.
- Which tenants should be included when deploying Releases: for example, you can ensure only Releases from certain Channels are deployed to certain Tenants.
Channels can also help you to create consistent Releases by specifying Version Rules that apply to each Package.
Channels are managed per project. Select the Channels menu item from the Project page.
Click Create Channel to create a new Channel.
The Channel must have a unique name per project.
You can associate a Lifecycle with the Channel, or it may inherit the default from the Project.
Defining Version Rules
Version rules assist in selecting the correct versions of packages for the Channel. They are only used when creating a release, either manually or via Automatic Release Creation.
SemVer works best
Version Rules will work best when you follow Semantic Versioning (SemVer 2.0.0) for your versioning strategy.
To add version rules to a Channel, click Add version rule on the Channel page.
The steps selected for a specific rule define which packages will be filtered on the Create Release page based on the following provided range and tag information. Note that either a version range or pre-release tag regex must be provided for a valid version rule.
A provided version range based on the NuGet versioning syntax can be applied to the release creation package selection.
You can use the full semantic version as part of your version range specification. For example:
[2.0.0-alpha.1,2.0.0) will match all 2.0.0 pre-releases (where the pre-release component is
>= alpha.1), and will exclude the 2.0.0 release.
Following the standard 2.0.0 semver syntax, a pre-release tag is the alpha numeric text that can appear after the standard major.minor.patch pattern immediately following a hyphen. Providing a regex pattern for this field allows the channel to filter packages based on their tag in a very flexible manner. Some examples are.
|.+||matches any pre-release||Enforce inability to push to production by specifying lifecycle that stops at staging|
|^$||matches any non pre-release||Ensure a script step only runs for non pre-release packages|
|beta.*||matches pre-releases like beta and beta0003||Deploy pre-releases using a Lifecycle that goes directly to a pre-release Environment|
|^(?!beta).+||matches pre-releases that don't start with beta||Consider anything other than 'beta' to be a feature branch package so you can provision short-term infrastructure and deploy to it|
|bugfix-||matches any with 'bugfix-' prefix (e.g. bugfix-syscrash)||Bypass Dev & UAT environments when urgent bug fixes are made to the mainline branch and to be released straight from Staging to Production|
Once a project has more than one Channel, there a number of places they may be used.
Controlling Deployment Lifecycle
Each Channel defines which Lifecycle to use when promoting Releases between Environments. You can choose a Lifecycle for each Channel, or use the default Lifecycle defined by the Project.
Modifying Deployment Process
Deployment Steps can be restricted to only run on specific Channels.
Variables may be scoped to specific Channels.
Deploying to Tenants
You can control which Releases will be deployed to certain Tenants using Channels. In this example, Releases in this Channel will only be deployed to Tenants tagged with
Early access program/2.x Beta.
Every Release in Octopus Deploy must be placed into a Channel. Wherever possible Octopus will choose the best possible Channel for your Release, or you can manually select a Channel for your Release.
Manually Creating Releases
When you are creating a Release, you can select a Channel.
Selecting the Channel will cause the Release to use the Lifecycle associated with the Channel (or the Project default, if the Channel does not have a Lifecycle). It will also cause the Deployment Process and Variables to be modified as specified above.
The package list allows you to select the version of each package involved in the deployment. The latest column displays the latest packages that match the version rules defined for the Channel (see version rules for more information).
Using Build Server Extensions or Octo.exe
When using one of the build server extensions or octo.exe to create releases, you can either let Octopus automatically choose the correct Channel for your Release (this is the default behavior), or choose a specific Channel yourself.
Automatic Release Creation
When enabling Automatic Release Creation for your project, you are required to select a Channel (if the project has more than one).
Any releases created automatically will use the configured channel. Additionally, any Version Rules configured for the Channel will be used to decide whether a release is automatically created.
For example, if version 3.1.0 of a package Acme.Web is pushed to the Octopus internal NuGet repository, and the Channel selected for Automatic Release Creation has a Version Rule as pictured below, then no release will be created.
If adding a pre-release tag to channels, you will also need to add the tag
^$ to your