The implementation of the 1.6 TeamCity plugin just has it as an extra setting under VisualStudio build step. It would be great if we could have this as a seperate build step.

We would like to be able to build our project, run tests and if all tests fail then package and publish to TeamCity's feed to Octopus to detect.

This isn't to big of an issue because TeamCity won't automatically deploy as it stands now. However if a user logs into Octopus and manually creates a release, they can select the potentially broken artifacts.

Normally, Windows Uninstall removes all program files, except those that have changed since the install (like config files and data files).
Currently the installer does not do this.

It would be great if Octo.exe could trace log output to the console window - instead of waiting for deployment. We integrate into a Continuous Delivery server (not Team City), and it would be good to be able to view errors in one place.

Our project deploys multiple packages and always uses the same version across all the packages per release. It would be nice to have a setting at the project-level to indicate this. This setting could allow the user to select the version once when creating a release and help prevent the user from accidentally entering a different version for one of the packages.

If octopus could scan packages for variables from Web.config, app.config and xxxDeploy.ps1, looking for appsettings and connectionstrings and $OctopusParameters[]. Then when adding variables it could suggest variable names. But also when creating a release it could warn about new settings/variables that have been added since last release and for which there was no variable?

Maybe it would actually be octopack that scanned for variable names and provided it as metadata in the nuget spec?

I use a SQL Project in Visual Studio using SQL Data Tools, it would be nice to be able to deploy to SQL using the DACPAC file it creates, as it can update the database using that file

CCtray the Cruise Control.Net Notfication Tray tool is a tool that polls a well known xml format and displays notifications on success or failure of builds. Team City now supports this format out of the box, and deployments in octopus actually follow a similar state pattern, where you could notify of a deployment by environment that is currently running, and report on the result of the deployment as success or failed.

Currently we have a couple ways to deploy. A main deploy which deploys our entire system 20 components (a service, website, etc) in one release. And adhoc deploys, deploys one component at a time. It would be nice to have a component view versus a release view the main point would be to show the state of each component and what version they are on.

For example, if an integration/selenium step has failed, it's nice to know the number of tests that failed. In order make this generic, having special messages in the build log (similar to how Teamcity does things http://confluence.jetbrains.com/display/TCD7/Build+Script+Interaction+with+TeamCity#BuildScriptInteractionwithTeamCity-ReportingMessagesForBuildLog) would be very helpful!

I have 30+ steps in my project. It would be great to be able to bulk change the nuget package version for each version drop down list.

Have an optional view of the dashboard (or a separate page) that pivots on version number. We have a lot of environments, and it gets hard to quickly view the dashboard and see which environments are out of date and don't have the same version. Having a list of Project->Version->Environment would help

User Group administration is cumbersome.

On the group administration screen add the ability to select multiple users at once instead of typing in user names.

On the user profile page show the groups a user is a member of. Administrators should be able to add users to groups from the profile page.

We run Tentical.exe in interactive mode rather than the service so that it can run selenium ui smoke tests after deployment.

When we update the tentical through octopus it doesnt seem to update tentical.exe and also restarts the service.

It would be great if deploying tentical updates from the octopus server would also update tentical.exe, idealy it would understand that tentical.exe is running interactivly and start this rather than the service after upgrade!

3 new powershell scripts, start, stop and status that will you be able to trigger from the web on each project in a machine and environment.

the status will tell you if the project is actually running or not (zero not running, 1 running) and will be probably be called every x minutes.

Sometimes variables contain sensitive information (e.g. passwords). Currently, it does not seem to be possible to manage permissions for variables on a per-environment basis. So a developer who is managing a dev environment, but does not have permission to deploy to production, might be able to see and/or edit variables which will be used for deployment to production.

The Octopus engine could identify a file in the root of the package, like "OctoVariables.xml" and automaticaly create or change variables in Project. Something like:

<variables>
<add name="MyConnectionString" environment="testing" value="User=test;password=1234;Initial Catalog=TestDb" scope="Step" override="false" />

<add name="DropAndRecreateApplication" value="false" override="false" />
</variables>

The ability to use variables exists in so many different places when setting up Kubernetes deployments, but one place I would think would make the most sense is the container image name.

When creating step templates, I found this one field a barrier from allowing me to use the templates because we use that image name for checking logs for various debugging.

As per the guideline on the user roles page, it is recommended to have the Octopus Deploy team create built-in roles where they are lacking. We have several users who would like the ability to view/create/modify subscriptions to get notifications about steps in deployment processes. At present we would need to either create a custom role or give them administrator rights for this. Please create a built-in role so we do not have the risk of managing this ourselves.