Product Feedback

Product Feedback

Categories

  • Hot ideas
  • Top ideas
  • New ideas
  • My feedback
  1. We have a tonne of variables. I am pretty sure there are some that are no longer used but I can't be sure so I am scared to remove them as I don't want to break the deployment.

    I think it might be a nice feature if Octopus could somehow track which variables were actually used during a deployment and therefore report on "unused" variables? Perhaps by adding a warning to the end of the deployment log?

    28 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    1 comment  ·  Deployments  ·  Flag idea as inappropriate…  ·  Admin →

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  2. This would allow Repeatable Release from Dev to QA to Prod.

    You would ask for value in begging of life cycle just like now,
    but for QA and Prod it would Retain that value entered in Dev as preset.

    thank you

    27 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    5 comments  ·  Deployments  ·  Flag idea as inappropriate…  ·  Admin →

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  3. When using an ARM resource group deployment, Octopus asks for parameters file, which is JSON, and replaces parameter values with matching variables.

    We would like to use the JSON variable substitution syntax mentioned here: https://octopus.com/docs/guides/deploying-asp.net-core-web-applications/json-configuration-variables-feature

    this would help us maintain a working parameters file that can be used outside of Octopus.

    27 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    2 comments  ·  Deployments  ·  Flag idea as inappropriate…  ·  Admin →

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  4. We have a nuget package which has been named after our tenants.

    We want to deploy the package as a part of our overall pipeline, however when we generate the release it wants a version number for that package, and each package has its own individual version, as some tenants have their package updated more often than others.

    We would like Octopus to resolve the Package Version at deployment time, just like it resolves the Package ID when using a variable binding expression.

    In this case it would be useful if you could specify "*" or "latest" (think docker) so…

    27 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    4 comments  ·  Deployments  ·  Flag idea as inappropriate…  ·  Admin →

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  5. Under our git process, we utilise feature branches quite frequently. However, this can result in some messiness in Octopus where feature branch releases are mixed up with mainline/master releases. It would be great if a release could be marked as feature/branch release of it was a mainline release and then filter on those release types in the project pages of Octopus. This could be similar to nuget's pre release tag.

    27 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  Deployments  ·  Flag idea as inappropriate…  ·  Admin →

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  6. On face value the (new-ish) Lifecycle and Release Blocking features of Octopus Deploy are very exciting, however there is a slight bugbear that makes them impractical for my workplace.

    We use continuous integration practices and as a result, all commits to shared source control repositories are automatically built and (if that build is successful) an automatic release is created / deployed to our development environment. Once the developers are happy with that release (in the development environment) it is then manually promoted to the staging environment for user access testing, after which it can be manually promoted to production.

    The…

    25 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    3 comments  ·  Deployments  ·  Flag idea as inappropriate…  ·  Admin →

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  7. Octopus Subscriptions should be extended to include support for running scripts (PowerShell, C# etc) in response to events. That, or allow the community to write their own extensions for Subscriptions (similar to how auth extensions were implemented).

    This would save us from having to setup an external webhook for Octopus to communicate with / cut out the middle man.

    23 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    5 comments  ·  Deployments  ·  Flag idea as inappropriate…  ·  Admin →

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  8. When adding a binding to IIS in Octopus, you can only use seperate variable. Every binding needs a new variable. Some of our deployments have over 50 bindings. We create each binding separate. If we use a variable list only the last item of the list end up in de IIS binding. It would help us a lot if we could ad three generic bindings (Test, Acceptation, Production), en in the bindings use a variable list, containing all the IIS bindings.

    22 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    2 comments  ·  Deployments  ·  Flag idea as inappropriate…  ·  Admin →

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  9. Sensitive variables pass to script as a String, so they could be written to file/socket. I think there should be an option to make those variables more secure and pass them as SecureString instead of String.

    21 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    2 comments  ·  Deployments  ·  Flag idea as inappropriate…  ·  Admin →

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  10. As of 3.0.11. prompt variables can only be scoped to environments. It would be good to be able to scope them to steps, roles and machines as well.

    21 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    6 comments  ·  Deployments  ·  Flag idea as inappropriate…  ·  Admin →

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  11. The FTP deployment step supports FTP and FTPS but not SFTP. Adding this would let Octopus users securely deploy to a much broader range of systems (i.e. Unix-y ones instead of Windows).

    21 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    3 comments  ·  Deployments  ·  Flag idea as inappropriate…  ·  Admin →

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  12. New-OctopusArtifact allows you to attach an artifact to a release. If you wanted to use that same artifact in another step on the same deployment, you'd need to use the API.

    It might not be such a bad idea to have a Get-OctopusArtifact cmdlet that returns info about that artifact, as well as a Download() method the download the full file from a Tentacle.

    20 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    4 comments  ·  Deployments  ·  Flag idea as inappropriate…  ·  Admin →

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  13. Offline install packages are a nice way of introducing Octopus and Calimari installs into an existing enterprise without having to directly attempt to change the change management process straight off.

    However in doing so one of the principal 'sell' points of Octopus - centralized logging - is lost.

    It would be nice if offline installation also took care of transmitting the installation logs back to the central server (presumably if possible), so the installs would look largely like any other install.

    20 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    1 comment  ·  Deployments  ·  Flag idea as inappropriate…  ·  Admin →

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  14. I have accidentally deleted projects multiple times now.
    When I am in a rush and want to manually recreate a release I have to delete it - which has a very similar sequence of actions required to delete the project! :(
    The only way to get the project back is to restore the database. It would be nice if you could just hide the project from the GUI and keep it into a trash can somewhere which could retain it for a limited perioud (e.g. a month).

    19 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    1 comment  ·  Deployments  ·  Flag idea as inappropriate…  ·  Admin →

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  15. We miss ability to undeploy a project from servers.

    Undeployment could run an Undeploy.ps1 script from the package that would contain logic for removing the service from a server (removing web app files, deleting databases, uninstalling a software).

    Currently there is no way to remove a project from a server if it is no longer used to run a service from the project (eg. changing where an web app will run, or removing programs installed by the deployment scripts).

    19 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    1 comment  ·  Deployments  ·  Flag idea as inappropriate…  ·  Admin →

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  16. When choosing to try again on a deployment it would be really nice to have an option to skip all steps that did deploy successfully.

    19 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    5 comments  ·  Deployments  ·  Flag idea as inappropriate…  ·  Admin →

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  17. As of 3.3 roles with in child steps are all-in: The childs will inherit all the roles from the parent

    Would the below feature be useful?

    • There's a parent step with 3 Roles "Role1","Role2","Role3".
    • Child 1 can be scoped only to "Role1".
    • Child 2 can be scoped only to "Role2" & "Role3".
    • Child 3 can be scoped to the 3 roles.
    • No child can be scoped to a role outside of the 3 defined by the parent.

    Source: http://help.octopusdeploy.com/discussions/questions/7673

    18 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  Deployments  ·  Flag idea as inappropriate…  ·  Admin →

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  18. This would ease the guessing work that needs to be done while trying to evaluate the release variables. This would also resolve any of the system variables that are needed to be used inside of the project variables.

    18 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    1 comment  ·  Deployments  ·  Flag idea as inappropriate…  ·  Admin →

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  19. I have read the section on not using dependencies (http://docs.octopusdeploy.com/display/OD/Packaging+applications) and I agree but I think we're missing a nice feature if we consider dependencies as being releases done by Octopus to a given environment that include the nuget that is defined as a dependency. Consider this:

    MyOrg.MyApp.Web 1.0.0.0 depends on MyOrg.MyServiceApp.RestApi 1.5.0.0...2.0.0.0.

    When I deploy MyOrg.MyApp.Web to environment Production Orcopus could check if I have a release in that environment that deuccessfuly deployed MyOrg.MyServiceApp.RestApi 1.5.0.0...2.0.0.0. Essentially this would make sure all my dependencies between projects are deployed within a given environment.
    It could also warn me about…

    18 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    1 comment  ·  Deployments  ·  Flag idea as inappropriate…  ·  Admin →

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  20. Currently when deploying a project containing one or more Deploy Release steps (https://octopus.com/docs/deployment-process/coordinating-multiple-projects/deploy-release-step), there is no ability to preview the deployment steps that will be executed in the child deployment, nor the ability to exclude machines from the child deployment.

    It would be nice to surface this information on the create-deployment page of the parent project.

    17 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    4 comments  ·  Deployments  ·  Flag idea as inappropriate…  ·  Admin →

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  • Don't see your idea?