Skip to content

Product Feedback

Categories

  • Hot ideas
  • Top ideas
  • New ideas
  • My feedback

522 results found

  1. There are times when I have one machine that failed a step and I want to retry that step for that machine only, then continue to deploy the rest of the steps for all machines.

    1 vote

    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  ·  Admin →
  2. When running powershell scripts, my understanding is that octopus just calls powershell.exe.

    Powershell.exe may default to running the script under .NET 2 or .NET 4, and octopus has no control over this currently.

    This can lead to situations where powershell scripts run on some environments, but not others, due to inconsistencies between the .NET version being used accross environments.

    There appears to be a simple solution to this problem, that will allow the tentacle to still work in the same way (calling a powershell exe) AND specify the .NET version that the script runs under. Read Tim Lewis's answer (at…

    1 vote

    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  ·  Admin →
  3. Prior to v3 of octopus, when a step required guidance the yellow box would indicate which step required guidance. Since v3 the guidance box no longer indicates which step it relates to and since multiple guidance boxes can appear you can end up clicking on the wrong one to continue when you've sorted out whatever maybe the issue.

    Please put an indicator of which step it is that requires guidance back in that yellow box.

    1 vote

    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  ·  Admin →
  4. When deploying a release, there is a selection box listing each available environmentn for deployment. If would be great if each environment would indicate its current release, if any. We have a multi-tenant application with some clients on a previous version, and we always have to take note beforehand which environments are applicable for a new deployment.

    1 vote

    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  ·  Admin →
  5. iam currently doing a full deploy to a staging envoirement were i do i backup/restore of a database and then set the certain values that is depending on the deployment, thats why when you create a deploy i want to be able to have some steps "skipped" by default.

    1 vote

    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  ·  Admin →
  6. TeamCity has the concept of Metarunners. These allow you to package up a sequence of build steps into a single new step and reuse the sequence across multiple builds. We have a standard set of approvals that are required for deployment to certain environments. It would be nice to be able to define these approval steps once and share it to all of our applications instead of having to manage the entire process in each application directly.

    1 vote

    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  ·  Admin →
  7. We have multiple solutions some contain both the c# application and the database project, some just contain the database projects and other projects contain items such as SSRS reports or SSIS packages. Each of these is deployed independently via Octopus. A particular business change may result in changing quite a few separate projects. So when we deploy to our test environment we need to deploy a series of project/versions in turn. We need to record the project/versions that have been deployed to test, so that when we come to deploy to production we can ensure that the exact same series…

    1 vote

    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  ·  Admin →
  8. I am implementing a large-scale deployment solution with Octous and TFS.

    I would like my build to trigger a deployment as soon as the packages have been built.

    We build around 40 packages in a five minute window.

    I am concerned that if I allowed the build scripts to trigger a deployment as soon as the package is concerned, we could end up with a massive amount of projects being deployed concurrently.

    I'd like to see, as a feature, the ability to set a max value per environment. Then, I can throw as many jobs at Octopus during my build…

    1 vote

    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  ·  Admin →
  9. We have a multi-tenant setup, with one environment per client. Since we often have multiple minor releases in production at a time, it would be great to see at a glance which version is currently deployed to each environment on the "Deploy release" screen (/deployments/create) so that it's easier to pick the right clients to update.

    1 vote

    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  ·  Admin →
  10. It would be good to have a control type of "Azure Subscription" in step templates, so that you can easily make step templates that runs under an azure subscription, rather than relying on the existing limited set.

    1 vote

    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  ·  Admin →
  11. When scheduling a future deploy, it'd be nice if the "Deploy release" button text changed to "Schedule release" (or similar) so the user is 100% sure they are scheduling a future release without having to scroll back up and double check.
    It would also be nice to also have the "The deployment will start in approximately ...." text that currently lives under the schedule date/time picker duplicated next to the button, again so the user can easily verify that clicking the scary green button is going to do exactly what they want.

    1 vote

    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  ·  Admin →
  12. We have an Octopus Deploy project that installs a significant number of Windows Services to a variety of servers. Quite often, we only need to deploy a partial set of the services, as a system patch.

    It would be useful to be able to define this partial deployment ahead of time so that it can be peer reviewed and signed off prior to any release.

    We tend to apply this patch to QA and then PROD environments, so this feature would potentially need to allow the user to define the subset of target machines for each environment; also ahead of…

    1 vote

    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  ·  Admin →
  13. Add Kerberos authentication for SSH deployment endpoints

    1 vote

    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  ·  Admin →
  14. Sometimes users need to deploy content to a sub directory within an Azure WebApp, but they dont want to include the complete webapp on the NuGet package. Currently Octopus will delete anything that is not on the NuGet package.

    A checkbox to avoid the files deletion and perhaps a field for "Custom Install dir" might be a good idea.

    1 vote

    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  ·  Admin →
  15. True. Powershell scripting is a powerful way of achieving more customized deployments. But not all will be well versed on scripting. Instead provide them with a UI which transforms their actions into powershell scripts used in deployments. And users can add more and more value to add by adding more actions thus making anything possible with respect to deployments. Scenarios might include taking machines out of load balancing and deploy set of services/applications and then joining them again and redo ing it for other machines. Improved and custom logging

    1 vote

    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  ·  Admin →
  16. We would like to see all the releases that contain a specific version of a package, therefore able to track what environments they were deployed to as well as its history. When we may be debugging you can get the version of a binary and then be able to track the package and when/where it was deployed.

    1 vote

    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  ·  Admin →
  17. Our deployment targets encompass 100+ tenants, so our deployment process encompasses multiple products within a consistently versioned suite of products.

    When we upgrade a client, they receive all components within our suite. However, some of our products support the ability for styling customizations that we like to flow through our standard/normalized release process -- these customizations get versioned in a distinct nuget package and can be redeployed within a release version. This means that our product version is redeployed multiple times for a given client if a new customization is created for a client.

    So our deployment process for this…

    1 vote

    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  ·  Admin →
  18. For debugging purposes it would be extremely useful if you could have a list of variables use for at given deployment or what variables were present at creation of the release.

    1 vote

    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  ·  Admin →
  19. We are using Octopus and different platforms with different environments.
    we have 4 platforms, each platform has 8 QA environments and 1 production environment.

    I would like octopus to implement the "Platform" concept. So you create at platform, in that platform you create environments. Projects are living inside the platform(Like today). You should be able to scope variables to a platform.

    1 vote

    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  ·  Admin →
  20. In the step templates, show which version of PowerShell the scripts work on, be useful to look at a glance and see which version they work against - the MSMQ - Create Transactional Queue only works on PowerShell version 4 and higher.

    1 vote

    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  ·  Admin →