Channels has shipped in Octopus 3.2!
- Read the blog post
- Read the documentation
- Look at the walkthrough
- Try out Channels as a Guest on our demo server
In the next version of Octopus we're planning to improve our support for people working on different branches of code. We're still in the planning stage on this one, so it's a good time to share what we're doing and get your comments.
Each time you create a release in Octopus, you choose the versions of each package to include, defaulting to the latest:
When different teams work on different branches at the same time, it can make the create release page difficult to use. For example, suppose that the team published packages in the following order:
Acme.Web.1.9.3.nupkg
Acme.Web.1.9.4.nupkg
Acme.Web.1.9.5.nupkg
Acme.Web.2.3.1.nupkg
Acme.Web.2.3.2.nupkg
Acme.Web.1.9.6.nupkg
Acme.Web.1.9.7.nupkg
Acme.Web.2.3.3.nupkg
Acme.Web.2.3.4.nupkg
When viewing the create release page, since Octopus defaults to the latest version, it means people have to hunt to select the right package version - not a great experience.
To help with this, we're introducing branches. You'll define a branch like this:
A branch has a simple name, and then a set of rules that decide which versions should appear when creating a release. In the Step name field, you can choose which steps to apply the rule to - one, many or all steps in the project. The Version range field uses the NuGet versioning syntax to specify the range of versions to include. The Tag can contain a regex, and is used over the SemVer pre-release tag.
On the create release page, you can select which branch to use, and it will control which packages appear:
A more complicated branch definition might be:
Here, the project has multiple steps. For the Acme.Util step, we have one rule, and we have a different rule for the other steps. We're using tags to only show packages with the -vnext SemVer tag.
Our goal with this feature is to keep it simple - branches really only matter from the perspective of the release creation page (and Octo.exe create-release). If you need different environments or deployment steps depending on the branch, it's probably best to clone a project.
So, what do you think? Would such a feature be useful to you? Let us know in the box below.
