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.

Any news?

Any update on the progress of this? I'd really like to generate a config file for an environment before I actually deploy. Thanks!

Any closer with this bad boy?

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.

Any update on this ? Especially a tool for web transformation will be a great help .

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

Is this still happening?

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.

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.

any update on this dry run feature.

"- 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

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.

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.

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.

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).

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.

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.

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.

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