'Dry Run' Deployment
Sometimes deployments are bad due to bad configuration variables that are un-testable before releasing to production.
Having the ability to 'dry run' a deployment and see all the task outputs with specific highlighting for variables and evaluated variables would allow the identification of changes that need to be made before actually deploying to an environment.
Vanessa Love
shared this idea
Work has begin on providing a tool to evaluate variables before deployment
https://github.com/OctopusDeploy/Issues/issues/4221
At the moment we don’t have further plans to apply config transforms before a release but this should help solve the bigger question of “what will my all my variable values actually be at run time”
25 comments
-
Chris M
commented
It looks like they addressed the 'sometimes there are bad variables' part of this, by allowing you to test variables in any step and at any environment, under the variables section of any project, not specifically by having a dry run.
-
Jan V
commented
Any news?
-
Douglas Waugh
commented
Any update on the progress of this? I'd really like to generate a config file for an environment before I actually deploy. Thanks!
-
Stephen
commented
Any closer with this bad boy?
-
Jamie
commented
Yes... this would be a welcome feature. As a new user I'm finding that it can be difficult finding proper values quickly. The ability to preview the deployment steps and the values that will be used would be an immense help and avoid some of the 'try and try again' routines I'm finding myself in.
-
Navdeep Singh
commented
Any update on this ? Especially a tool for web transformation will be a great help .
-
Anonymous
commented
Yes we'd like to see the "diff" in the state of variables compared to current Before actual deployment so we can double check them
-
Rohin
commented
Is this still happening?
-
Stanislav Hordiyenko
commented
This would be really helpful if I can check that my refactoring didn't brake anything. I am doing it frequently as variables come and go, and I need always to work with them.
-
Anthony Geoghegan
commented
This should allow users to view the results of the "variables within variables" feature for the various prospective deployment options available. A simple dialog just like the variable scoping dialog could be used to vary the parameters to adjust what the resolved variable values would be.
-
Mahfooz
commented
any update on this dry run feature.
-
Adam
commented
"- Ability to preview the evaluated variables for an environment/step/machine/tenant combo"
I would love to see this available from the API. That would enable us to speed up our migration considerably. We have scripts to parse our existing configurations by env and add to octo api, but they dont have the ability to check env specific values across library sets."we are thinking of either creating a tool,"
I would expect to see this as a new command in octo.exe -
Denis Pujdak
commented
It will be helpful for me too. I'd like to see Deployment Preview before release within information which instances are included, their old versions and where they are going to be. Thanks.
-
Nithin Shenoy
commented
A Dry Run or Preview mode would be fantastic. Based on this (http://help.octopusdeploy.com/discussions/questions/7680-previewing-transforms-and-substitution) discussion, I created a powershell script that uses the output of a "Drop Target" to make the transformations. See https://repne.wordpress.com/2016/06/10/previewing-octopus-web-config-transforms-via-offline-package-drops/ for the complete steps. It's hacky, but works. Something native in Octopus itself would be much more preferable.
-
Tim Thompson
commented
We have a large percentage of 'first' deploys to an environment fail purely due to the mental tax of trying to project the current variable configuration into it's final deployed state. An ability to 'dry run' and eyeball the resulting config files would almost entirely eliminate the need for our current practice of deploying to an environment _before_ it's required simply to confirm config values are correct.
-
TdeRoo
commented
This is a good idea, since we've had a situation where a deployment failed due to incorrect variable scoping which took us several days to find (needing Octupus Support). The fact that one of the key variables was undefined was not clear in the deployment log (even with octopus debug variables set).
-
Tim Gebhardt
commented
Yeah or if there was a view that allowed you to see that variables in use by other environments are "missing" from this environment and have been used, or something like that.
-
David Keaveny
commented
This suggestion definitely gets my vote. Especially when deploying to a new machine for the first time, there's too much an element of crossing fingers and hoping that you didn't forget one variable setting out of several hundred.
Just being able to say something like "Do a dry run of project X deployed to environment Y", and having Octopus then describe each step, and particular what the variables will be, would save so many fails-so-update-variables-and-try-again scenarios.
-
Boz
commented
Really, really need this feature. Have been bitten a few times on releases to production because that is the first time you actually see what variables are replaced on each machine. No number of beta deployments can give you confidence that your Production variables are correct! I actually need to see variable setting by Environment, Machine Role, and Machine. Or at least the option to choose that level of detail and review variables that apply for that scope.
-
Michael Christensen
commented
If you have a setup with a lot of variables targeting different steps/roles/environments, it becomes difficult to predict what the exact variable values delivered to each step will be.
For instance, I might have forgotten to define an important variable scoped for our production environment. My deployment script will then fail because the value is missing.
It would cut down on the deployment error rate if it was possible to ask a release to show the variables that would be available in each of the steps associated with it, given an environment.A nice to have would be to be able to compare which variables are available to the same step in the different environments side-by-side, to spot variables available to only a subset of the environments