We are just looking at deploying Octopus into our production environment and a feature that would be useful would be being able to assign an environment to a release when a release is created,
This would prevent anyone from deploying a release to the wrong environment and would allow the release to be pre approved with a manual step.
In Octopus a single release gets deployed/promoted to multiple environments. You can use Project Groups to control which environments a project can be deployed to, but any release can be deployed to any allowed environment.
Could you describe the scenario above in more detail? What would the purpose of “assigning” an environment to a release be, rather than say creating the release and then deploying it immediately to Production?
Currently we have a number of projects and these each map to a system. Within the project variables and steps are defined. This project is then used to create a relaese that can be deployed to the test and then to the production environments so that the release is tested and there is consistency.
We are just about to open Octopus out to a wider user base and there is a concern that when deploying a release it will be too easy to select the wrong enviornment from the drop down and deploy to the Production rather than test environment.
If we created a Production project group and only listed the production environments as being allowed wouldn’t we need to duplicate our system project within both groups? Then at that point you run the risk of differences arising between the two copies of the project.
Thanks for providing more details. I wonder if either of the following approaches be good solutions for this problem?
Approach #1 - Use a manual deployment step that only applies to Production deployments, and asks for approval from someone in a team who can verify that the deployment is actually supposed to go to production?
This might or might not be used in conjunction with a permission setting that stops most developers from being able to deploy to production.
Approach #2 - what if Octopus allowed you to set up rules like:
- You have to deploy a given release to development, test and UAT (successfully) before you can deploy it to production?
Thanks for the prompt response, Approach 1 was something we were considering our development team are in the process of upgrading to the latest octopus version so we can test.
Appproach 2 may be useful as long as the ability to override these rules was available as they is always an exception to the rule.