Nithin are you talking about in the release page? If so then the deployment status should already be visible, including if it's paused for manual intervention (icon looks like an eye). Could you log a ticket through supportoctopus.com along with screenshots so that we can investigate?
Work has begin on providing a tool to evaluate variables before deployment
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”
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.
Based on this discussion (http://help.octopusdeploy.com/discussions/questions/7680-previewing-transforms-and-substitution), I went ahead and sort of created my own tool. I created a little powershell script that will take in a variable JSON file from a drop target, a web.config, and a web.foo.config transform file and spit out a transformed file with the final substitutions. Here's a link to the GitHub Gist: https://gist.github.com/nshenoy/79ac16c84edcc65485dff263d1e2781f . This is just an initial stab at it, but seems to work ok for what we need. Hopefully someone may find this helpful. If something like this was native in Octopus, it would be incredibly helpful (and probably more stable than this hacked up script).
Thanks for voting on this suggestion. We’re working on a number of changes to the step template library, and this is one of them. It should ship in the next month or so.
Another idea would be to have templates as folders. The folder would have the script and a sibling json metadata file. This would be somewhat similar to hubot scripts or VSTS extensions. Bottom line, the scripts need to be in a format that is readable and easily reviewable by a human outside of Octopus (e.g. windiff, GitHub diffs, etc).