While we make great of environments and machine roles for our production servers and devices, we still find it difficult to manage certain test scenarios without having to maintain a very large collection of test environments in order to mimic each distinct production environment. It would be nice to have an option, at the deploy time, to override or set certain variables, allowing a single test environment that can be dynamically configured to use various settings.

Some of our services have large config files and we will allow some settings to be defaulted (not configured through the Octopus UI) and others must be configured. I would like a Project Level setting to be included that if enabled would decorate the deployed config file with some indication that Octopus overrode the setting. This would help tremendously to be sure which settings were defaulted and which were set by Octopus.

Step template should not run if minimum power shell version is not met.

Currently, OtcoPack considers a project a web application if a web.config file is found in its root. My stand-alone ServiceStack service project needs to have such a file when working with Razor support to enable intellisense support in VS. The web.config is never deployed however but OctoPack now deploys the project in web-style. That is, copying all binaries to the 'bin' sub directory while they should really go into the root. See https://github.com/OctopusDeploy/OctoPack/blob/fa2bbe0ce4b489316e090bf35f4d7d74d1d3a92a/source/OctoPack.Tasks/CreateOctoPackPackage.cs#L463

We've had a couple issues where something in the Queue froze and stopped all future deployments. When it's a project that seizes up, we can cancel it, however when it is an internal task (e.g. Tentacle Health Check), the only way to fix the issue is go into Raven Studio. I know I can see the completed tasks, but I would like to be able to view the queue, and perhaps cancel jobs from there as well.

I use powershell to determine information from TFS/VSO to store in the nuspec before octopack does its work. One of the values I set is the author of the package is the person that committed the build. Unfortunately this is not displayed in the library of the website.

I.e. you can specify how a deploy is done, but someone else has to push the button.

Via @DerAlbertCon at https://github.com/OctopusDeploy/Issues/issues/1063

It would be nice if it may possible to set the --packageversion for octo.exe over the GUI.

Currently i do this with additional parameters, but i would be nice if i can easy choose like

latest
same as releaseversion
userdefined

I stumbled over a problem that it was not directly visible that the latest version from nuget will be taken, it took me a while the get this and how to change that.

When I have many Queued tasks and then go to the Tasks page, I have to scroll down to see the Active task. I suggest the Tasks page be grouped by Active task, then Queued tasks, then Recent tasks.

When creating a release the user is given three options to configure a package version for each step, Latest, Last, Specifc. The default is Lastest.

Allow the user to specify the package version default behaviour in each step.

The user could then ensure a package stays at a particular version without having to set the version each time they create a release.

We need the ability to view all the variables in a release snapshot including those coming from step templates

Ability to specify version of PowerShell during script execution.

Currently tentacles use the default path, which is great most of the time! You could currently call PowerShell with a command line parameter but any scripts have to completely re-written to work this way, which defeats the simplicity of Ocotopus!

http://technet.microsoft.com/en-us/library/hh847899.aspx

If I want to edit a project group, I must first navigate to the "all projects" overview page. Would be nice to just have an edit icon in the "Projects" dropdown for easier access.

Create an Octopus variable that contains the last installed directory paths for the steps in the project. This becomes useful if you have one step that deploys and another that works on the previously deployed step, but for some reason you deployed one set of steps first and later the remaining steps.

Today if I select to have the instance count use the count from the Azure management portal and an instance isn't pushed yet (if I had deleted it for example) then it will fail and I have to go in an set it to the value from the config file and then switch back to use Azure mgmt. I'd prefer that it would fallback to the config file if it's not deployed in Azure yet.

For PowerShell scripts it would be good to know the deployment start time.

This way later scripts can report how long a deployment took up to that point.

(A current workaround is to have a script run at the start that sets a variable for later use by other steps)

Hello

I find it important to check the actual contents of the folder i am deploying to, in order to be sure that everything worked as expected.
Wouldn't it be great to have an embed file manager to see the folders and the files of the server you are deploying to?
Every server, every environment, every project, with user management, and permissions...

this would come in handy, even without deploying something really, just checking files, altering something in servers, without having to remote desktop, or use ftp etc. All centralized.

thanks