Product Feedback

Product Feedback

Categories

  • Hot ideas
  • Top ideas
  • New ideas
  • My feedback
  1. The variables view is very basic and it generally needs improving since it quickly gets hard to use when you begin adding lots of variables.

    1. You have to add the same variable name for multiple environments and the ordering of environments is not the same. This is error prone and makes the list hard to parse.
    2. There is no description for variables so you need to add very long names sometimes. This has already been covered, but I added it for completeness. See https://octopusdeploy.uservoice.com/forums/170787-general/suggestions/6079578-enhance-the-variable-maintenance-screen-with-varia
    3. There can be different types of variables which are changed for different reasons. It would be…
    420 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

    47 comments  ·  Installation  ·  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)

    Thanks everyone for your suggestions. We are happy to announce that a new version of the Variable Editor has shipped in Octopus 4.0! See https://octopus.com/blog/octopus-release-4-0 for more details.

    In this first release, we have focused on providing a great variable editing experience, which we hope you will love! Although we haven’t yet been able to implement all of your great suggestions, we have been able to build an extensible variable editor that we will continue to improve in future.

  2. Currently, a deployment targets a project and an environment.

    Some customers have applications that they host for many customers, with each customer having their own set of configuration options applied. Their application may not be designed to support multi-tenancy, and instead is deployed separately for each customer.

    To handle this in Octopus currently, they either duplicate the project many times, or they duplicate environments many times.

    We should build in the concept of a "Tenant" as a first class concept that can be enabled. Each Tenant will have a name and a set of associated variables. When deploying a project,…

    388 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

    30 comments  ·  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. At the moment when editing a step, you can specify which environments it is to be run in. Selecting no environments means that the step will run in all environments. There's no way to specify that a step should run in no environments.

    If I have a problematic step and I'd like to take it out of use temporarily while I work on it, I'd like to disable it somehow, maybe with a checkbox on the process page.

    Source: http://help.octopusdeploy.com/discussions/problems/23854

    302 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

    35 comments  ·  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)
    Released  ·  Paul Stovell responded

    Hi, thanks for voting on this suggestion. Good news: we’ve added the ability to disable deployment steps in Octopus 3.5.5. I can’t believe it took us this long!

  4. This was originally raised at https://octopusdeploy.uservoice.com/forums/170787-general/suggestions/6186352-version-control-of-deployment-scripts and closed as completed with a solution of scripting the import/export tool.

    Raising as a new suggestion as this has come up as few times in support calls and some people have suggested on the original thread that the import/export tool doesn't meet their needs. (Didn't want to reopen the original thread as some people are happy with the provided solution in that thread.)

    "In the Continuous Delivery book, Jez wrote that your deployment scripts should be in source control. After creating some pretty elaborate powershell scripts for Octopus, I have to agree. Losing…

    299 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

    34 comments  ·  Integration  ·  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. I want to use template-all model, where all projects consists only of step templates, to provide central management of deployment process. But when i modify step template, I need to manually go into every project and into step and click "update".

    I think it would be better to use TeamCity model, where template can only be inherited and not changed inside project, or cloned from template if changes needed. Or provide the ability to one-click update all steps that uses the template (even better ask for it after click on Save button).

    I'm going to end up with 30+ projects,…

    262 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

    35 comments  ·  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. Make it possible to scope permissions to a project group.
    This should also allow the "project initiator" role to allow projects to be added to a specific project group.

    Source: http://octopus-deploy.tenderapp.com/discussions/questions/1990-project-group-and-ad-group-security

    209 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

    23 comments  ·  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)
    Released  ·  Paul Stovell responded

    Thanks for voting on this feature. We shipped Octopus 3.6.1 today which supports scoping team permissions to a project group, in addition to projects. This means you can allow team members to create projects as well as to do other things with the projects they create, within a project group.

  7. In the Continuous Delivery book, Jez wrote that your deployment scripts should be in source control. After creating some pretty elaborate powershell scripts for Octopus, I have to agree. Losing those scripts or having them damaged would be pretty painful.
    I understand Octopus has backups, but it would be better to be able to get back to a previous version or see where the script had changed. Since we use GIT, I would be completely satisfied if GIT integration was all that you supported. :) I hope this is helpful. Thanks.

    200 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

    33 comments  ·  Integration  ·  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. Please support deployments of the new Azure Service Fabric "microservice" architecture platform.

    See http://azure.microsoft.com/en-us/documentation/articles/service-fabric-overview/ for the initial documentation and Channel9 build videos.

    199 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

    22 comments  ·  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. Currently, all machines use the Tentacle agent, which is Windows only.

    Add the ability to register machines via an SSH endpoint instead.

    During deployment, the Octopus server will push packages to the SSH endpoint, and then run Bash scripts (just as we currently run PowerShell scripts).

    198 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

    16 comments  ·  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. It would be great to have an ability to create a recurring scheduled deployment, such as each Monday at 9:30 pm promote from QA to Staging

    Source: https://octopusdeploy.uservoice.com/admin/tickets/1640

    189 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

    25 comments  ·  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. Add RO attribute/flag to variable set to prevent accidentally changes of it. Or even develop extended permissions linked to username, groups etc. For example in our Octopus environment we have default variable set in library for special package and I'm afraid if somebody will change it accidentally and it will affect to whole related projects where it will be used

    187 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

    21 comments  ·  Installation  ·  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. We have about 40 steps in our deployment process. Moving to rolling deployment it is very labor intensive as each step has to be deleted an created again as a child step. This is not very user friendly. I want to be able to more easily move our steps around to optimize our deployment process.

    So the suggestion is to extend the reorder functionality to support moving steps in and out of rolling deployment groups

    168 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

    19 comments  ·  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. 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.

    161 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

    9 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)
  14. There are multiple places within Octopus where you can set 'conditions' on something by limiting it to a set of machines, or environments, etc.

    It would be nice if we could extend this UI to allow the 'inverse' to be selected too.

    Examples are:

    • A step that only runs for a given environment -> users should be able to say "only the X and Y environment" (which they can do now), or "all environments except X and Y" (which they can't)

    • Deploying to a subset of machines (advanced deployment settings) - again you can include machines, but not exclude them.…

    145 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

    11 comments  ·  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 have several deliverables that are usually deployed on individual schedules, thus each deliverable equates to its own Octopus Project. There are occasions when we have coordinated releases of many of our projects. In these situations, it would be an improvement to have the ability to define releases for individual projects as we can do now, but group these releases together into a "System" release which includes several "Project" releases.

    143 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

    28 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)
    Released  ·  Paul Stovell responded

    Implementing this as described would make for quite a complicated UX. A deployment takes a release of a project, and applies it to an environment. So you’d have to select all the projects, then the releases for those projects. Not to mention getting the order/dependencies right. I can’t see us building something specific for this in the near future.

    With Channels in 3.2, I think this scenario can be modelled differently. Say a project has 5 components which are sometimes deployed independently, and sometimes all at once. You could simply create a channel for each of the components, and an extra channel for “Full release”. Steps can then be scoped to each channel and the Full Release channel.

    When creating a release, you can then choose whether it’s for just one of the components or all of them, and the UI will change as appropriate. And best of all dependencies…

  16. We have many dependencies between our projects. So for example we have cross database dependencies which mean that a particular version of the database must be installed prior to another version. Similarly we have base services that are required by all others that must be installed first. There is currently no way of telling Octopus that one project depends upon another.

    We could create one great big Octopus deployment with all the steps in it to deploy the TFS projects/libraries in the correct order. But this would be very complicated because of the large number of dependencies.

    It would be…

    142 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

    15 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. 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).

    139 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

    10 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)

    Happy to announce we’ve added a usage tab to the variable set page in 2019.5.4, where you can view which projects and releases are using a variable set. While this does not cover all suggestions below, we are confident that this goes a long way to solving the problem.

    Finding the usages of individual variables is something that is a lot more complex than it sounds, and we are unlikely to implement. Many variables usages are embedded in strings, or even in files sourced from packages, meaning any results we displayed would be incomplete.

    If you think we’ve misinterpreted this suggestion, please raise a new suggestion with a bit more detail about the use case, and let us know in the comments below.

  18. It would be nice if I could clone steps inside processes. For example if I want to deploy two nuget packages, I need to create one step to deploy a nuget and again create another step to deploy a nuget, instead of just cloning it. It's a waste of time!

    129 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

    22 comments  ·  Integration  ·  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. Offline drops don't currently support passing output variables from a deployment package step to another step as part of the same deployment script. Would it be nice to add them?

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

    121 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

    16 comments  ·  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. Octopus is a deployment orchestration/application release automation tool. Many companies can benefit from configuration management tools like Puppet/Chef, but for various reasons are unable to use them. On the Windows platform, PowerShell's Desired State Configuration support is designed as an alternative to Puppet/Chef, and makes it easy to automate tasks like configuring Windows features and checking for drift.

    However there are limits to using PowerShell DSC for our customers - they may not always be on the same AD domain, there may be security issues, there's no auditing, and no nice central way to manage scripts for the team.

    Octopus…

    105 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

    12 comments  ·  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)
← Previous 1 3 4 5 17 18
  • Don't see your idea?