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.

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

Some of our projects live on shared servers, and run under different users for isolation. It would be good to be able to choose which user a nuget deployment/powershell script runs under so we can protect against mistakes/malicious code in our powershell deployment scripts.

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!

It would be nice to have a Role dashboard.
Eg. application 1 = role 1 and an overview where all applications (roles) will be shown in a grid

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

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.

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.

When viewing a Release, I would like to be able to clone the Release into a new Release. The variables, package versions, etc. of the new Release would be set to the same values as the original Release.

This would help support hotfix scenarios, where we have the previous Release saved, and want to deploy just a single updated package. Right now I basically create a new Release and manually set all of the package versions to the existing values. The manual method doesn't allow me to copy the older set of variables though.

Currently the option is to use a userid and password to connect with the nuget package feed. It would be great to not enter username and password but use the same api key used to push the packages into Myget.org to retrieve them

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.

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!

I think it would be a nice feature to be able to rename roles, there are situation where you might choose the wrong name and at that point if you have many project connected to it it will be annoying to have to update all the projects.

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.