General
-
Version control configuration
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…
574 votesThanks everyone who voted on this. We’ve spent a lot of time thinking about how best to version control Octopus configuration, and came to an approach that is a little different to what was imagined in this blog post. I just published an RFC post with our plans – I’d really appreciate if you could take a look and leave a comment!
-
Integration with Microsoft Teams
Microsoft Teams already has a pretty great list of connectors, but one big one is missing... Octopus Deploy!
I would like to be able to receive messages in a channel when a deployment is complete, or certain events happen.
227 votesActively working on a Microsoft Teams tab.
-
Environments per project
The problem is, when you have multiple projects, is not very common that they share the same environments.
"Production" for "Project A" means a very different thing than "Production" for "Project B". Different machines or group of machines in case of a web-farm, for example (Deployment Targets).
Currently, the only way that this could be solved, is by creating custom environments per-project (ProjectAProduction, ProjectBProduction), as discussed in the support site (http://help.octopusdeploy.com/discussions/questions/10999-environments-per-project)
But this is more a workaround than an actual solution. The home page Dashboard gets really messy, because you can't filter environments for certain projects.
I think…
36 votes -
Release Manager
Often times with our release we are deploying multiple configurations. With the way octopus stands now you would have to manually go and deploy each project. What we did was created our own tool that uses the API that allows us to deploy multiple projects at once to a particular environment. Something like this might be nice to build into Octopus Deploy itself.
3 votesA feature that will do just this will be available in the next few weeks in version `2018.2.0`
Take a look at our blog post for more details!
https://octopus.com/blog/deploy-release-step/deploy-release-step -
'Dry Run' Deployment
Sometimes deployments are bad due to bad configuration variables that are un-testable before releasing to production.
Having the ability to 'dry run' a deployment and see all the task outputs with specific highlighting for variables and evaluated variables would allow the identification of changes that need to be made before actually deploying to an environment.639 votesWork has begin on providing a tool to evaluate variables before deployment
https://github.com/OctopusDeploy/Issues/issues/4221At the moment we don’t have further plans to apply config transforms before a release but this should help solve the bigger question of “what will my all my variable values actually be at run time”
-
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.
221 votesthe feature Composite Step Templates has started which should meet most of these requirements. The underlying templates will still be linked so that they can be updated as per normal step templates.
-
When deploying a release to an environment, default the Comments from all the Release Notes since the last deployment to that envioronment.
Part Two of a 2-part idea.
When we deploy to production we generally would like to, include in the comments all the release notes from all the releases since the last deployed-release to that environment.
But it IS admittedly a bit of a chore.
If Octopus did it, then it wouldn't even be a chore at all and we would continue to love Octopus and feed it plenty of sailors!
<3 u
131 votesWe are implementing this in conjunction with some tighter integration to the work item trackers (like Jira and GitHub). Release coming soon.
-
Allow "Configure Features" in "Run Script" steps
I want to be able to say, transform a json file, and then run a script.
Right now the only way to do that is by putting your script into a nuget package, naming it "publish.ps1", using the "Deploy a package" step and targetting it somewhere, then enabling configure features.
1 voteThis is under development now.
We are adding all the configuration transform features to the Script Steps.
The plain is to ship this in the August 2018 release.
-
Allow Azure powershell steps to run on servers other than the OD server
The Azure powershell steps run on the Octopus server, which is good for ease of getting up and running and small projects, however it is not great when you've got a lot of steps and a lot of projects. This is especially painful when you've got lots of steps that take time. If a cloud service takes 3 minutes to deploy, and you've got 6 to deploy, that blocks the server for at least 18 minutes.
This would probably be even more useful if implemented in conjunction with https://octopusdeploy.uservoice.com/forums/170787-general/suggestions/6316906-support-run-on-any-tentacle-model-for-deployment.
I know that some people would prefer still to keep…
5 votesWe have started this, follow https://github.com/OctopusDeploy/Issues/issues/4158 for details
-
Allow updating of existing Step Templates via the Import feature
The ability to import step templates from other locations (e.g. Octopus Library) is awesome, but if someone updates the step template the import process can not be used to update the copy I have in my Octopus server. I'm forced to delete the step template and re-import it. Obviously if I have N projects that rely on the step template I'm now stuck because I can't delete it when projects are using it.
Since I can technically update the powershell script and change parameters and so on inside of Octopus Deploy UI itself, importing of existing step templates should just…
24 votesThanks for voting on this suggestion. We’re working on a number of changes to the step template library, and this is one of them. It should ship in the next month or so.
-
Previous deploy variable for environment
I would love to have a variable available that is similar to Octopus.Release.Previous.Number but instead list the previous release number for the specified environment not the project.
9 votesNew variable names will be in 3.0.
https://github.com/OctopusDeploy/Issues/issues/1496 -
PowerShell desired state configuration
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…
251 votesThanks everyone who provided feedback on this ticket. We published a blog post yesterday showing how to do PowerShell DSC with Octopus – everything from deploying DSC scripts, detecting drift, getting email notifications when drift occurs, and automatically fixing the drift:
https://octopus.com/blog/octopus-and-powershell-dsc
With that in mind, I think many of the comments on this suggestion are “done”. But there might be some areas of DSC support that we still don’t do. I’d really appreciate if you could read the post, and let us know of any scenarios we’ve missed. If it looks like we’ve done nearly everything, I might close this UserVoice suggestion and we can open new, more targeted suggestions for any gaps.
- Don't see your idea?