We have multiple different types of deployment and I need a little help sorting out which Octopus feature fits best in each case.
We have these deployment types:
- Beta and Prod - current version of the product, use dedicated environments. Each build is deployed to Beta and SOME of them get promoted to Prod.
- vNext - next version of the product (Alpha), also uses different dedicated environment. Built from the different Git branch.
- Sandbox - very much transient test deployments usually done by developers or PMs in self service mode to their own VMs. Need to be able to deploy from either current or vNext branch.
From documentation it seems to me that Beta and Prod are two lifecycle stages of the same Project.
vNext looks as a separate Channel to me. What is the way to direct packages from particular branch to specific Channel?
Sandbox is confusing. We need to let developers create their AdHoc environments and deploy any Release (from either branch) there. How to do it with Octopus UI?
Thanks for getting in touch.
Regarding Beta and Prod, yes, having two lifecycle stages of the same project would be a good approach here. Once you’ve deployed Beta and are happy, you can then easily promote to Prod.
Using Channels for vNext is a good idea. Regarding package selection for Channels, please see the “Defining Version Rules” of the Channels documentation for an example. When you’re creating a release, you select your channel and the version rules will help define package selection.
For Sandbox, do you use a build server like TeamCity/Jenkins etc? Ideally you’d have your developers commit to branches and your build server would build the packages and push to Octopus. For a more detailed explanation, please see the Pushing packages to the build-in repository documentation. If you wanted these deployments to be automatic, you could investigate Automatic Release Creation so that Octopus automatically deploys those new packages to your sandbox environment(s) for you.
You can create teams to help manage what your developers can/cannot see in Octopus. This may help if you want your developers to manage their own environments/deployments, but not have full Octopus administrator rights for example.
Hope this helps.