Version Control of deployment scripts
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.
This suggestion has been forked and a new one raised at https://octopusdeploy.uservoice.com/forums/170787-general/suggestions/15698781-version-control-configuration. If the import/export tool works for your situation, thats great. If it doesn’t, please vote on the new suggestion and add any thoughts you have about how you’d like to see it work.
That's a great idea.
Mark Evans commented
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.
Peter Karaganis commented
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.
Sam “Betty” McKoy commented
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.
Chris Barr commented
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?
Wayne Brantley commented
Would have been better to just introduce Git/Mercurial/tfs repository support - and then we could just point OctoDeploy to our repo....bam done...
Jakob Strauch commented
+1 for tfs integration :-)
Bart Read commented
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.
Jon Kennerly commented
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.
John Crim commented
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.
John Crim commented
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.
D Lemos commented
The most single important feature to implement on a new major version.
Peter Goodman commented
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.
Martin Jæger commented
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.
Dag Nygaard commented
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.
Ryan Rousseau commented
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).
Job Vermeulen commented
@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.