That's a great idea.

Agreed.

The logic should follow very much the same approach Ansible Tower has taken w/ Ansible. Or how Amazon Opsworks has for Chef.

Let me give you a git repo with all scripts. You should define a folder structure.
From within Octopus Server it should always do a checkout of repo before a deploy.

I really like the Team City approach to version control for builds. I think something like that would be a giant leap forward to implementing a version control solution for deployments.

I think the entire release configuration should be able to be read from the NuGet package. That way it's independent from source control but can be stored in source control if I choose.

The editing experience won't be as nice as I'd be editing a JSON (or similar) file instead of using a GUI, but has a lot of other merits.

Maybe I'm missing something, but how is import/export the same as having version control on all the build steps? Looks like this is a manual process... yea, we could export and manually put them into source control - but we'd need to do this automagically everytime we change something? Is there any plans to have all build steps just auto version controlled?

Would have been better to just introduce Git/Mercurial/tfs repository support - and then we could just point OctoDeploy to our repo....bam done...

+1 for tfs integration :-)

I'd add a big +1 for this although, as others have said, not just for git. I run across a reasonable amount of TFS and svn in the wild as well, so think it would also be worth supporting at least those two.

Would a GIT repository be the only option? Those with the "main code line" in TFS or other might not want to utilize multiple SC providers.

I would recommend that you support exporting + importing a developer-readable config file for each project. And probably separate the variables into another file just to make them really easy to track.

Even better would be the ability to make the versioned project configuration the authoritative source of project configuration. It would be clunky to require a manual export + commit each time a config setting or variable is changed, if you want your vcs history to match the history of the project configuration.

I think it's important that the entire project configuration, and optionally properties (excepting password properties - passwords shouldn't go in version control), should be commitable to source control. Then you can track all changes to the project in a single place.

Teamcity is now supporting committing build configuration to source control.

The absence of this is a major drawback from using Octopus relative to our current deploy system.

The most single important feature to implement on a new major version.

We are really keen to see this feature. We've identified this as one of the major areas of concern for us. TeamCity has a pretty good approach to this although at times it can be hard to attribute the reason for a change without commit messages.

SQLite seems like a sensible choice. The Raven indexing issues we have had after an export+import migration are very concerning.

This would be so awesome.
Transparency in configuration-changes is key.
Would you also put variable-values in git? Or store these in RavenDB to better control sensitive data like passwords.?

This would be handy if it just had an export option so you can save them to any kind of repository not just git, export process steps alone would be handy right now.

I support the suggestion that deployment scripts should be managed in a way that administrators may version control current process steps in a configuration file, for instance OctopusDeploy.config.xml.
- I can then use whatever version control system I prefer.
- I can retrace my steps (if I use the version control system as intended)
- I can move OctopusDeploy from one server to another much easier.

We currently put our deploy scripts in our source control with the projects we deploy. When we build the nuget package, we just make sure that it is copied into the correct folder as Deploy.ps1

Would love to see this! Improved git support as a backend would be awesome.

One of they key principles introduced in the Continuous Delivery book is to 'store absolutely everything in version control'. Having Octopus configuration and scripts outside of that is less than ideal given it's role in application delivery.

Ive recently been working on a POC for deploying Sql scripts and its not ideal to paste text into the script block or create a nuget package with a ps1 file. This feature would convert me more to using Octopus for production releases in our company (250+ devs).

@Paul, I don't think your latest post describes the complete solution.
I care more about the steps with their settings.

That's something different then a attachment from Git.