Octopus Deploy 3.2 was released on 3 November 2015 and is available here.
Features
Octopus Deploy 3.2 is all about Channels which is the name we've given to the feature originally discussed in our RFC on Branching.
Build servers build. Octopus deploys.
We decided it was important to drive a distinction between source code branches, which build servers care about, and deployment, which is where Channels come in.
Channels
In a software project you may want to treat certain Releases differently, and Channels in Octopus Deploy make this easy to manage. Each Channel can have a different Lifecycle, different Variables and a different Deployment Process. We've designed Channels to make it easier to implement, manage and evolve more complex deployment scenarios.
While it is possible to model complex deployment scenarios in Octopus Deploy without Channels, it usually involves cloning Projects which introduces its own set of complications.
We think the best way to get started with Channels in Octopus Deploy is to explore some of the deployment scenarios we've encountered, and how Channels can help in each scenario:
- Safer standard release promotion
- Supporting multiple versions (evolving deployment design)
- Hotfix deployments
- Early access programs
- Feature branch deployments
Scenario 1: Safer standard release promotion
Matthew is enhancing and fixing bugs on the latest release of his Company's flagship product. He wants to push his code changes and have them automatically deployed to a Dev environment, and then let his test team promote releases through a Test environment, and finally to deploy releases to Production when they are ready. He also wants to build pre-release packages, but wants to prevent those from being accidentally deployed to Production.
This is a very typical scenario and Octopus Deploy already supports this scenario without the need for Channels, except by adding a simple Version Rule you can prevent pre-releases from being accidentally deployed to Production.
Note: Version Rules will work best when you follow Semantic Versioning (SemVer) for your versioning strategy.
Scenario 2: Supporting multiple versions (evolving deployment design)
Version 1.x has just shipped, and Andrew is starting work on 2.x. As part of 2.x Andrew needs to introduce a new service which needs some new Steps and a handful of new Variables. He would like to start shipping pre-releases as soon as he can. In the meantime Stephanie is enhancing and fixing bugs on Version 1.x, and wants deployments of 1.x to work the same as they always have.
In this case Andrew could create a new Channel called 2.x Unstable, and scope the new Steps and Variables to that Channel so they only get included in deployments of 2.x. He can also configure Version Rules to make it easier, and safer, to create Releases of either 1.x or 2.x making sure the right packages and deployment steps are used.
Since Andrew took the time to create the 2.x Unstable Channel, Stephanie can continue to deploy 1.x Releases confident the deployment process will still work, and won't accidentally include any 2.x packages by mistake.
Scenario 3: Hotfix deployments
Stephanie has just received an alert that the checkout process in Version 1.x is failing in Production due to a problem with a 3rd party integration. The remedy is a simple code change to the Order Processor service and she wants to deploy an emergency hotfix release to Production without delay.
Thankfully in this case Stephanie had already planned ahead and created a 1.x Hotfix Channel that uses a Hotfix Lifecycle. Now she can create the hotfix Release in the Hotfix Channel and deploy it straight into Production, and then back-fill the release into Dev and Test.
Scenario 4: Early access programs
Andrew is ready to start sharing early builds of 2.x with a specific group of trusted Beta Customers. He would like to deploy specific pre-release builds to a Beta Environment and notify these Customers of the new pre-release.
In this case Andrew can configure a new Beta Environment, Beta Lifecycle, and 2.x Beta Channel. Now he can deploy Releases directly to a new Beta Environment, and prevent them from being promoted to other Environments. He can also configure a new Step, scoped to the Beta channel to send an email to all of the early access Customers with the URL to the new Beta release.
Scenario 5: Feature branch deployments
Sarah is starting work on a new feature for Version 2.x called Multitenancy and she wants to make sure people can test her work as soon as possible without interrupting other work going on in Version 1.x and 2.x.
In this case Sarah can create a Channel called 2.x Feature Branch, and some Steps scoped to that Channel which will automatically provision an environment in the public cloud named by a convention based on the Tag part of the Release Version. She can even use a Script Template to post the details of new Feature Branch deployments into their team chat.
Now that Sarah spent the time creating the 2.x Feature Branch Channel:
- when anyone in her team pushes a new feature branch they will get a notification a few minutes later with the URL to the test environment for their feature that was just provisioned and deployed, and
- when anyone pushes new code to an existing feature branch, the new code will be deployed to the existing test environment for their specific feature
- at any time they could delete the hosting environment and provision it again by deploying a Release
Backwards compatibility
We’ve designed this feature to be unobtrusive and backwards compatible. If none of these scenarios apply to you, or you already have your own way of managing them, you can pretend Channels don’t exist, and use Octopus Deploy exactly as you did previously.
In Summary
Now that Channels is complete, check out our roadmap to see what's coming up next! Don't forget to take a look at our RFC for Octopus Reactions - Integration Toolkit and get involved in designing the future of Octopus Deploy.
Happy Deployments!
