I've not used Octopus Deploy that much, at present, but I have found that the variables and the configurable nature of the steps to use these variables is key to what I have done so far, and what I'd like to do and use more efficiently going forward.

At present, I find the variable screen/page a "problem" to work with if there are more than about 20 or 30 variables.

In my view, requirements of this "Variable" screen/page would include:

• Be able to filter the variables to a specific "Scope" so you can see what attributes will apply for a particular Environment, Role, Target or Step (or combinations of these). This would be really useful for debugging what variables are being passed to a target/environment. Or limit them to those used by a particular project or step etc.

• As part of the above, it would also be useful if, where you had variables defined as other variable's values, you can see in the preview the value it was actually outputting based upon the resolution of the variable references/hierarchy.

• Be able to see variable references used in the variables (and be able to see a list of all usages of variables that didn't exist and warn/prevent if trying to delete a variable where there was a reference to it that did exist)

• Renaming a variable renames all references where used (at present you have to manually change them in the processes, for example, I believe). Or you should be blocked from renaming if there is a dependancy - i.e. create a new variable, remap the references, then delete the old one.

• If there are variables of the same names (that use different scopes) then these variables should be grouped into one summary group/entry that can be opened/expanded to show the different variations of that variable. This would also be good if it would show which Scope combinations hadn't been covered by the logic (setting up the same variables with different scopes leaves the opportunity for missing one of the logical scope combinations).

• Being able to group variables into sets per Octopus Deploy server, per user group, per Project, per Environment, per Target, per Role, per process, and even per Step would give added flexibility. A number of the build tools provide the ability to define a hierarchy of variables at application, project and step level - They work quite well in my opinion.

• Access to create/amend/modify variables could be granted against one or more of the above scopes so granularity of permissions can be suitable to requirements.

• At present, if you have the same variable with different scope configurations, but the scopes of those overlap, it seems to be a "random" chance of which value is returned. I'd suspect the interface/page should stop this happening and not leave it open to non-deterministic outcomes.

• There is another suggestion on loading variables from a configuration file. I'd suggest this may also provide some use if you didn't know the variable values until you built the solution you were to deploy.

• An audit history of variable values (i.e. when they changed and what they changed to) - This might be useful if something breaks as a result of a change and you need to see the last working value.

• Coupling the above point, with the point about seeing what variable values were being used in a particular scope, this could even be "at a particular point in time" if Octopus was storing an audit of the changes.

• Being able to Order by Scope (i.e. the items within Scope such as Target or Environment).

There are a number of items I've listed above but I'm sure I've not covered all the points/frustrations I have come across. I'll add comments if I remember any more. I hope that provides some food for thought and consideration.

Other than the variables screen, I'm enjoying using the tool.

Cheers,

Paul