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 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."

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 that configuring environments per project could be something worth for you guys to analyze.

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 the existing model, so it would be useful to implement as an option, rather than forcing everyone to switch to a tentacle based solution for this.

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 offer to do the same thing and update the pieces for me.

We use tentacles primarily as machines that deploy code to Azure, thus they act more like "Deployment Agents" than "Deployment Targets". As a result, it would be nice to be able to configure a project/step/etc. to run on the first available tentacle in a pool (defined by environment/role/whatever).

Right now, if I were to have a role "azure-deployer", and I had multiple tentacles in that role, my steps would run on ALL tentacles in that role. Instead, I'd like to be able to have it run on the first available tentacle. Of course, an alternate solution (that we are using as a workaround) is to give each project its own tentacle (sometimes sharing a machine with other tentacles), but this is less flexible given that all we need is for the deployment process to pick ANY available tentacle.

Anyway, we're loving the product, and are able to work around this issue, but this would be a cool feature!

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 could build in support for DSC, and this would make it much easier for customers to create DSC configurations and apply them to machines managed by Octopus.