522 results found

1. Enable worker pool support for 'Deploy a Package' step

   We have nearly a dozen client/WPF projects that primarily consist of backing up a directory and then overwriting it with an updated package (size ranging from 20-350MB). Each of these projects push their packages to 20 remote servers, but the servers cannot host tentacles due to our security policies, so we run the steps from one of our Octopus hosts (via tentacle installed alongside the manager service). This is slow and expensive on the Octopus host, especially when there are many other deploys underway. Worst of all, it forces steps to deploy in serial versus parallel because all steps are running through a single agent.

   After reading a bit on workers and worker pools, I thought they might provide a solution for our bottleneck by offloading the work from our Octo servers and enabling parallel deployments. However, after building a pool, I realized worker-enabled steps are seemingly limited to cloud and scripts. If I was pushing these packages to an S3 bucket, I’d be good to go, but I cannot choose a worker pool as the execution location for the ‘Deploy a Package’ steps we are using. I’ve also considered using PS scripts to push these packages around, but we enjoy using built in configuration features to uniquely configure each remote locations files.

   Can worker pool support be enabled for the ‘Deploy a Package’ step so I can use workers to push packages to remote Windows servers?

   We have nearly a dozen client/WPF projects that primarily consist of backing up a directory and then overwriting it with an updated package (size ranging from 20-350MB). Each of these projects push their packages to 20 remote servers, but the servers cannot host tentacles due to our security policies, so we run the steps from one of our Octopus hosts (via tentacle installed alongside the manager service). This is slow and expensive on the Octopus host, especially when there are many other deploys underway. Worst of all, it forces steps to deploy in serial versus parallel because all steps are… more

   9 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   2 comments  ·  Deployments  ·  Delete…  ·  Admin →

2. Allow Scheduled Deployment Triggers to not re-deploy if targets are up to date

   Currently, the Scheduled Triggers option allows setting a time to deploy, and even includes examples in the documentation for "nightly deployments." The downside currently is that it will re-deploy every single night, even if the environment was already successfully deployed to.

   It would be nice to add an option to only deploy if the environment / targets need it done. This would allow for a real nightly promotion without excess deployments and logs.

   9 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   1 comment  ·  Deployments  ·  Delete…  ·  Admin →

3. Deploy to Service Fabric

   The 'Deploy to Service Fabric' process does not provide all the available security mode options available in Service Fabric, we are doing a POC around an on-premise SF cluster using a gMSA which the Fabric will run under the context of and Windows Identities to allow client-to-node communication. the option for using Windows Credentials (in this case it would be the Windows Service Account which Octopus is running under the context of) to connect to the cluster is not available! i.e.

   Connect-ServiceFabricCluster -ConnectionEndpoint <cluster-domain-name | server hostname>:19000 -WindowsCredential

   9 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   5 comments  ·  Deployments  ·  Delete…  ·  Admin →

4. Add repository retention feature for external feeds

   Add repository retention feature for external feeds. I'd like to be able to manage package retention on external feeds in the same way that they are managed for the internal feed automatically deleting unreleased packages after a number of days

   9 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   1 comment  ·  Deployments  ·  Delete…  ·  Admin →

5. Version rollback, or viewing of previous versions in Step Templates

   Hi OctoDeployers! My team have been working on standardising a lot of the work we do in Octopus, and its great that the step template function allows us to create and edit standardised steps, and then roll them out to our projects.

   One challenge this has presented however, is that if you introduce a defect when updating the version of the step template, there isn’t a way of:

   Seeing the previous version of the step template to confirm your changes
   The ability to roll back to a previous version of the step template.
   You can perform some of this functionality in some places, like the script step, by using script inside a package however that doesn’t exempt you from making mistakes in your step template, only reduces it.

   Step templates and Octopus’ roll forward/roll-back versioning are awesome features for us. Any chance of these features entering a newer version of the tool?

   Hi OctoDeployers! My team have been working on standardising a lot of the work we do in Octopus, and its great that the step template function allows us to create and edit standardised steps, and then roll them out to our projects.

   One challenge this has presented however, is that if you introduce a defect when updating the version of the step template, there isn’t a way of:

   Seeing the previous version of the step template to confirm your changes
   The ability to roll back to a previous version of the step template.
   You can perform some of this functionality… more

   9 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   1 comment  ·  Deployments  ·  Delete…  ·  Admin →

6. Tentacleless deployments using WinRM

   Now that Octopus Deploy can do deployments via SSH, it seems like it would be fairly simply to implement the ability to do deployments by connecting over Windows Remote Management (WinRM).
   Agentless deployments is a selling point used by other deployment tools, and now that Octopus Deploy can do "agentless" deploys via ssh, it would make sense to enable the same support for Windows machines as well using native Windows functionality.

   This would provide several potential advantages depending on the deployment infrastructure:
   - No service needs to be running on each deployment machine
   - No additional firewall port needs to be opened for listening tentacles if the WinRM port is already listening and connections are not blocked by the firewall.
   - No tentacle maintenance

   Now that Octopus Deploy can do deployments via SSH, it seems like it would be fairly simply to implement the ability to do deployments by connecting over Windows Remote Management (WinRM).
   Agentless deployments is a selling point used by other deployment tools, and now that Octopus Deploy can do "agentless" deploys via ssh, it would make sense to enable the same support for Windows machines as well using native Windows functionality.

   This would provide several potential advantages depending on the deployment infrastructure:
   - No service needs to be running on each deployment machine
   - No additional firewall port needs to… more

   9 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   2 comments  ·  Deployments  ·  Delete…  ·  Admin →

7. Environments screen to filter by Tentacle or Calamari updates

   In v4, it would be helpful to know how many machines in each environment need Calamari and/or Tentacle upgrades (possibly next to the health indicators on the right?)

   As of right now, customers can't see (from this overview) which servers need updates.

   At a minimum, we need an API filter that allows us to search for servers that need Tentacle or Calamari updates.

   Source: https://secure.helpscout.net/conversation/479027453?folderId=557077

   9 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Deployments  ·  Delete…  ·  Admin →

8. Make 'Release Notes' mandatory when creating a new Release

   It would be really nice if you could configure 'Release Notes' to be mandatory when creating a new 'Release'. Part of our deployment process is that we must enter Release Notes, so being able to make them mandatory would be really useful!

   9 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Deployments  ·  Delete…  ·  Admin →

9. Enhance the Octopus IIS Web Site step Virtual Application to include Authentication settings.

   Enhance the Octopus IIS Web Site step Virtual Application to include Authentication settings.

   9 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   1 comment  ·  Deployments  ·  Delete…  ·  Admin →

10. confluence

    It would be really cool if you could link your Octopus Deploy releases to a page in Confluence. I guess you can already do that with a custom script but it'd be good if there was a better way.

    9 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  Deployments  ·  Delete…  ·  Admin →

11. Programmatically change order of machines in rolling deployment

    We have a windows service (that is apart of a Windows Cluster) deployed through Octopus Deploy. To continue to have high availability of this service during deployment, we use a parent rolling deployment step, with two child steps. The first child step checks to see if the current node Octopus Deploy is deploying to is the owner of a Windows cluster group, if so, move it to the next available node. The next (last) child step deploys the windows service associated to that cluster group (which is now no longer active on this node).

    This works great, but it would be awesome if I can tell Octopus Deploy which machines to deploy to first, to provide the least amount of "failovers" (moving cluster group to a different node).

    i.e. I can have all non-owner nodes of the cluster group to be deployed to first, before the active owner node. This ensures of only having to failover (move) the cluster group once.

    We have a windows service (that is apart of a Windows Cluster) deployed through Octopus Deploy. To continue to have high availability of this service during deployment, we use a parent rolling deployment step, with two child steps. The first child step checks to see if the current node Octopus Deploy is deploying to is the owner of a Windows cluster group, if so, move it to the next available node. The next (last) child step deploys the windows service associated to that cluster group (which is now no longer active on this node).

    This works great, but it would… more

    9 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  Deployments  ·  Delete…  ·  Admin →

12. Octopus Deploy to remember the value passed for the variable during promotion

     We have multiple-clients deployment so going with the model Clients are set up as Environment
    
     We have our Development Team and IT-Operations (ITOPS) Team . The reason for the request raised is because both teams do have access to each other’s environment so DEV Team do not know how many environments are set up and ITOPS team does not have access of DEV Environments or variables . Hence as Dev team we cannot scope any variable to a specific environment controlled by ITOPS .
    
     The option left with DEV team is to use the prompt option in Variables to notify ITOPS team with the introduction of new variable .

     Now what we require here is that once (for the first deployment after introduction of a new promoted variable) the ITOPS has entered the value for the prompted variable during promotion of the release to a specific environment/ client , Octopus Deploy should remember the value and use the same for the variable without re-prompting during future promotion/release to the same environment . BUT
     The value for the prompted variable then should be saved under variable scoped to the environment so that the user is be able alter according to our client’s requirements in future if needed.

     We have multiple-clients deployment so going with the model Clients are set up as Environment
    
     We have our Development Team and IT-Operations (ITOPS) Team . The reason for the request raised is because both teams do have access to each other’s environment so DEV Team do not know how many environments are set up and ITOPS team does not have access of DEV Environments or variables . Hence as Dev team we cannot scope any variable to a specific environment controlled by ITOPS .
    
     The option left with DEV team is to use the prompt option in… more

    9 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    2 comments  ·  Deployments  ·  Delete…  ·  Admin →

13. Octopus server "linking"/clustering

    I haven't thought this through 100%, so i'm just going to ramble a little..

    We're sitting in a PCI environment where we're required to have a separate installation of Octopus in our production environment. Currently, the solution is to have our build server push packages to both our internal and production environments (we're allowed to use HTTPS over a site-to-site VPN for specified services).

    The biggest downsides to this are that:

    1) Without setting up complex build configurations for each project in our CI server (time consuming and maintenance nightmare), all packages get pushed to the production environment, even if the releases are later rejected in QA/UAT.

    2) Increased risk of human error since we can't use the "promote" workflow.

    3) Must manually re-create and configure projects in the production environment (human error risk as well).

    It would be superb if we were able to link these two instances together via an HTTPS connection where:

    1) Once a release reaches a specified "gate" (e.g. UAT release accepted), the release could be promoted to a linked Octopus server instance (push nuget packages, etc.), where the production release could be handled from there (we have separate logins to our production Octopus). I suppose the release could be flagged as "pending release" or something in the dashboard, indicating action needed. In this case only accepted releases would end up in the production environment.

    2) Specify which projects can/should be synced to which linked servers (in-case of several separate environments running different projects).

    3) Flag variables as needing to be re-configured in the production environment (e.g. we would rather keep our production connection strings only on the production Octopus instance, and not specify them in the internal instance). A promote-to-instance should fail if these haven't been re-configured.

    4) It would be nice to be able to visualize the release status in environments on linked servers.

    And naturally there's a lot of other nifty features/etc. that could be built around/on-top of this...

    I haven't thought this through 100%, so i'm just going to ramble a little..

    We're sitting in a PCI environment where we're required to have a separate installation of Octopus in our production environment. Currently, the solution is to have our build server push packages to both our internal and production environments (we're allowed to use HTTPS over a site-to-site VPN for specified services).

    The biggest downsides to this are that:

    1) Without setting up complex build configurations for each project in our CI server (time consuming and maintenance nightmare), all packages get pushed to the production environment, even if… more

    9 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  Deployments  ·  Delete…  ·  Admin →

14. Performing dry run with octo.exe push (--whatif)

    Looking at the documentation for “octo.exe push” (https://octopus.com/docs/api-and-integration/octo.exe-command-line/push), but I cannot see any option to perform a dry run. The ‘create-release’ command has a ‘whatif’ param, and it would be really handy to have this on the ‘push’ command as well.

    8 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  Deployments  ·  Delete…  ·  Admin →

15. Add additional output variables to Terraform Plan step stating if changes required

    Terraform plan step currently only outputs "TerraformPlanOutput", however this always has values and is not easy to run conditional steps upon.

    When running terraform with the --detailed-exitcode (https://www.terraform.io/docs/commands/plan.html#detailed-exitcode), you're able to determine if there is a change required.

    It'd be good to output this as an output variable.

    Specifically, my use case is that if there are terraform changes required I want to require manual intervention (and send a slack message) for the plan to be approved. If no changes required then don't require intervention, don't run plan, dont send slack notification.

    8 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    1 comment  ·  Deployments  ·  Delete…  ·  Admin →

16. Support creation of releases in child projects during "Deploy a Release" step

    The new "Deploy a Release" step is great! However, it was unclear to me at the time of setting up the steps that the "Deploy a Release" step does not actually support creation of a release before deployment--the release must already be created in the child projects before deploying.

    While this step is definitely headed in the right direction, in my opinion, I would think this feature would be even more useful if it also supported the ability to create a release in the child project(s) before deploying.

    The package versions are already supplied to the projects when creating the parent project's release, so I would think it could naturally use the package version supplied at the time of parent release creation to create releases in the child projects when deploying. I'm not really sure what to suggest if that release already exists in a child project, though--maybe just prevent the release until the conflict is resolved.

    Thanks!

    The new "Deploy a Release" step is great! However, it was unclear to me at the time of setting up the steps that the "Deploy a Release" step does not actually support creation of a release before deployment--the release must already be created in the child projects before deploying.

    While this step is definitely headed in the right direction, in my opinion, I would think this feature would be even more useful if it also supported the ability to create a release in the child project(s) before deploying.

    The package versions are already supplied to the projects when creating the… more

    8 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    1 comment  ·  Deployments  ·  Delete…  ·  Admin →

17. allow projects to have default tenants

    i have a few projects with one tenant purely to enable easy filtering of environments and shared settings between tenant projects.

    any time i deploy the project i need to select the one and only tenant to do so. would be nice if i could set that particular tenant as the default option for all deploys.

    8 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    1 comment  ·  Deployments  ·  Delete…  ·  Admin →

18. Add ability to update individual variables in a release

    Sometimes an old release requires new variable values, but not all of the new variables are compatible with the release. For example, variables from global variable sets have changed that will break the release.

    It would be nice, instead of updating all of the variables in a release, to chose which variables to update.

    8 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    2 comments  ·  Deployments  ·  Delete…  ·  Admin →

19. Per channel version templates

    I would like to use different version template for each channel so I can have a different format version numbers for my experimental channel then my main production channel

    8 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    2 comments  ·  Deployments  ·  Delete…  ·  Admin →

20. Make it easier to create a new release and select "last" packages instead of "latest".

    Many times the new release is based on previous packages, but just a change in the process or variables.
    Currently the default behaviour of creating a new release is that the selected packages in the new release are the latest found on the feed.which requires manually going throughout all the packages (could be a few dozens sometimes), and clicking on "last".
    If the default would be change it would make it easier, or alternatively - even better, add a button "Select All" on-top of each column (lates/last) which will allow easily selecting the required packages at once.

    8 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    4 comments  ·  Deployments  ·  Delete…  ·  Admin →