Allow kubernetes ingress to specify TLS configuration.

We need to use C# code as script in the script modules

When working with library variable sets used in many projects with many steps it is cumbersome to figure out where a given variable is used.

When updating a deployment process, certain tasks become very difficult, such as:
-Renaming or deleting a variable
-Checking validity of a newly-updated variable value across all usages

With a "find all" feature these tasks would be much simpler (plus I'm sure there would be wider-reaching benefits).

It would be great to see Python listed as a script step. Python is heavily utilized in the infrastructure space, AWS, F5, Citrix, VMware and will help to drive full automation further up the stack.

We have multiple projects being deployed to different servers in heterogeneous environments. Some are just test-production, others are dev-test-staging-production. The projects often have completely separate environments.

It would be beneficial to be able to either choose which environments a project can deploy to, or to be able to set up per-project environments to be able to keep the same names for config transforms. (ex. "Web.Test.cfg" instead of "Web.Test-Product1.cfg")

Currently the Dashboard is also very "cluttered" with empty boxes due to those environments not being in use for certain projects.

We have "major deployments". At this time we have to deploy all our applications (~ 70) at once. So it would be nice to have a possibility to deploy all projects from environment-1 to environment-2

The Set-OctopusVariable (and its counterparts for other scripting languages) should support an -IsSensitive flag such that if a variable is marked as sensitive it will not leak into a log.

Ideally variables can be read without expanding the browser to both windows - probably a bug

Screens:
https://ufile.io/nf3ps

The new Docker features debuting in recent versions of Octopus are really promising, and I'm excited by the Docker Compose RFC published late last year.

Kubernetes is becoming increasingly popular as the production deployment environment of choice for containerised applications. It offers functionality very similar to Azure Service Fabric, in terms of auto-scaling and self-healing of services and applications, but is based around container images rather than zip files.

I just updated to the new 4.0.3 version of Octopus. I do NOT like the process to skip deployment steps. It is hard to follow and see what is going on and takes way longer than the older versions. Please change this to something more like the older version where I can see all the steps and easily click on the ones I want to skip.

One of the people on my team couldn't even figure out how to skip the steps it was such a pain to find.

Right now only manual intervention steps cannot be skipped during a custom deployment. It maybe good to be able to mark any step as unskippable.

Allow C# and F# scripts to include references to NuGet packages that are downloaded and referenced before the script is run (see http://scriptcs.net/).

Preferably the feed could be any defined feed and not just NuGet.org.

It would be nice to have the option to run different steps based on the status of the previous step (failed or completed successfully). Sort of like an If/Else statement. This way, you can roll back changes if a certain step fails within the deployment process.

PowerShell debugging feature uses special variable Octopus.Action.PowerShell.DebugMode which only allows to turn script debugging on and off. Any real deployment contains many steps and many scripts, out of which only one particular script is under debugging, not all of them.
I propose to make DebugMode selective.
One way to achieve it would be to use special variable to configure step name (or a list of step names) where scripts run in debug mode.
Another way (may be combined with the first) is to let PowerShell scripts to invoke debug break explicitly, exactly where and when it is needed.

When you got a lot of microservices inside a group, one click to start deployment for all of them in their defaults lifecycle

We are working on a feature to allow storage and management of X509 Certificates within Octopus.

https://github.com/OctopusDeploy/Issues/issues/2701

If you have any comments or suggestions, please post them to the GitHub issue.