6 results found

1. Store sensitive variable values in Azure Key Vault

   So sensitive project variables will be referenced from Azure Key Vault instead of being stored in octopus.

   https://azure.microsoft.com/en-us/services/key-vault

   3357461 - 'Azure Resource Manager Key Vault support' was only about ARM template Key Vault support.
   17973586 - 'Integrate Octopus deploy with secrets managment system Vault' is similar to this issue only for https://www.vaultproject.io

   This idea is similar to
   https://docs.microsoft.com/en-us/vsts/build-release/concepts/library/variable-groups?view=vsts#link-secrets-from-an-azure-key-vault-as-variables

   148 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

   Under Consideration  ·  16 comments  ·  Integration  ·  Delete…  ·  Admin →

2. Composite Step Templates

   There are sets of common steps that we very often want to "bookend" all of our deployments with. One concrete example would be: sending out a Manual Intervention to confirm when all servers are confirmed live before stamping a new deployment in NewRelic.

   Right now, everyone has to bake these steps into their own projects by adding the Manual Intervention step followed by the NewRelic Deployment Stamp step. If it were possible to create what I would call "Composite Step Templates" then I could define a reusable step template that was made up of other step templates. That way, instead of everyone having to repeat all of the possible steps in their own projects, they would simply include this one composite step and they'd be done.

   Now, my composite example was only two steps to keep it simple, but you can imagine maybe a composite is made up of more than that. Or even imagine a change in policy where the Manual Intervention email has to include more information. Everyone has to repeat this stuff in all their projects and having the ability to put it into a composite step would alleviate all of that.

   There are sets of common steps that we very often want to "bookend" all of our deployments with. One concrete example would be: sending out a Manual Intervention to confirm when all servers are confirmed live before stamping a new deployment in NewRelic.

   Right now, everyone has to bake these steps into their own projects by adding the Manual Intervention step followed by the NewRelic Deployment Stamp step. If it were possible to create what I would call "Composite Step Templates" then I could define a reusable step template that was made up of other step templates. That way, instead… more

   366 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

   Under Consideration  ·  40 comments  ·  Deployments  ·  Delete…  ·  Admin →

3. Automatically retry steps if they are failed

   Now when a step failed you have to set guided failure on in order to retry the step, it would be handy to have a setting where you say always retry failed steps.

   For example if you are doing continues deployment where a build server triggers a deployment from a build, you have to:
   - login into octopus
   - select the correct project
   - manually intervene and assign it to you
   - retry it

   It would be much better if the retry can be done automatically

   215 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

   Under Consideration  ·  26 comments  ·  Deployments  ·  Delete…  ·  Admin →

4. Inheritable Templates

   There should be the possibility to create project templates which can be chossen when creating a new project. This should then not only copy everything, but keep the reference to the template. So when something is changed in the template, all projects based on this template should be updated as well.

   Steps coming from a template should not be editable in a subproject, but there should be the possibility to disable a specific step in a specific project.
   Also there should be the possibility to add other steps between "template steps" to customize the process.

   Teamcity has a simillar model.

   100 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

   14 comments  ·  Projects  ·  Delete…  ·  Admin →
   Under Consideration  ·  AdminProduct Team (Admin, Octopus Deploy) responded

   We have no specific work in progress at the moment, but we are actively listening in this area. Please continue to share specific scenarios.

5. Integrate smoke tests for post deployment

   While we can run smoke tests by using the PostDeploy.ps1, such as running nunit.exe or something similar (frisby.js, etc), it would be great to have a way to integrate back into the dashboard (through the rest api?).

   Related links:
   http://help.octopusdeploy.com/discussions/questions/214-running-smoke-tests-after-deploy
   http://help.octopusdeploy.com/discussions/problems/53646

   http://jimblogdog.blogspot.co.uk/2012/08/walk-thru-using-wolfpack-to.html

   118 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

   18 comments  ·  Delete…  ·  Admin →
   Under Consideration  ·  Paul Stovell responded

   Thanks for the suggestion and for voting everyone. I’d like to get feedback on where we should go with this.

   There are a few things in Octopus that already help with this – first, it’s possible to package your NUnit tests and run them as part of a package test (we do this ourselves), or to write a PowerShell step that pings your website to see if it is online. So the actual process of performing the tests is pretty easy. Do we need to write more blog posts/documentation to show how it can be done?

   The next part is viewing the test results – in Octopus 2.0 you can “attach” files to a deployment via PowerShell which are then uploaded and available on the deployment page.

   Viewing NUnit results XML isn’t that nice though, so I guess it would be nice to be able to render those NUnit test results in the browser, or to add ‘badges’ to a deployment (such as the number of tests passed). Is that all that is missing to mark this feature as “done”, or is there more we would need to do?

   Thanks again for the suggestion!

   Thanks for the suggestion and for voting everyone. I’d like to get feedback on where we should go with this.

   There are a few things in Octopus that already help with this – first, it’s possible to package your NUnit tests and run them as part of a package test (we do this ourselves), or to write a PowerShell step that pings your website to see if it is online. So the actual process of performing the tests is pretty easy. Do we need to write more blog posts/documentation to show how it can be done?

   The next part is viewing the test results – in Octopus 2.0 you can “attach” files to a deployment via PowerShell which are then uploaded and available on the deployment page.

   Viewing NUnit results XML isn’t that nice though, so I guess it would be nice to be able to render those NUnit test… more

6. Parallel deploy throttle

   Currently you can throttle the number of package aquisitions and the number of machines which will run steps in parallel.

   We see issues whereby too many steps run on the same machine causing out of memory issues.

   Can you please add configuration to limit the number of steps running in parallel on a single machine

   6 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 →
   Under Consideration  ·  AdminProduct Team (Admin, Octopus Deploy) responded

   We continue to watch this space for what we might do to better address per-worker management. If there are specific scenarios you are grappling with please let us know.