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.

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

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.

Sometimes when deploying, the user receives this message:

"For consistency, this deployment will use a snapshot of the variables and deployment process that was taken when the release was created, which does not include the latest changes that have been made to the project. A changed process can only be incorporated by creating a new release (this one may be renamed if desired). Variables can be updated via the release page, clicking Show to show the variables from the snapshot, and clicking the Update variables button."

It would be great to be able to tell the user exactly what changed, so they can make a judgement on whether or not to update variables or create a new release.

In my mind zero-downtime deployment is the gold standard of deployment. Octopus should support this model to the fullest. Given proper tooling (in Octopus) this is very easy to accomplish for customers.

I think most ASP.NET apps should be deployed in the following way:

1. Put the app behind a load balancer such as ARR (built-in and free)
2. For each new deployment create a *fresh* IIS site
3. Configure the site
4. Request a configurable set of important URLs to start the site and warmup caches
5. Validate, that those URLs return 200 and contain a given check string (a smoke test)
6. If all is OK, switch the HTTP route to the new site
7. After a few minutes the old app is drained. No more requests are in-flight
8. After 20min IIS automatically shuts down the now idle old worker process but it stays functional

It should be possible to easily switch back to old versions. A history of N (= 10?) old fully functioning versions should be kept.

We accomplish: Zero-downtime deployments. Not even app startup time. Safe deployments because the stage site was smoke tested. Ability to rollback instantly. Those are very valuable.

Manually configuring a Blue/Green system is not enough. It should be integrated into Octopus and require minimal developer expertise. I want *you* to build and support this. I don't want to be able to make mistakes (for example by letting the B/G configuration diverge or by deploying to the wrong slot).

It should not be necessary to write significant amounts of own scripting code to accomplish things. Scrips are often broken and error cases are not well-tested. Building as much of this as possible into Octopus removes sources of errors and gives confidence. Confidence in deployments is very valuable to customers.

If Octopus can support this model with minimal developer effort and with a high degree of confidence then this is clearly the new gold standard of deploying in .NET. There would be no reason *not* to do this. Using Octopus becomes a no-brainer.

In fact it is hard to find an automated solution for Blue/Green style deployment right now. It has not been productized yet. That's what's prompting this feature request.