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 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."
AdminOctopus Developer
(Software Engineer, Octopus Deploy)
shared this idea
Thanks 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!
18 comments
-
Matthew Hodgkins
commented
I've begun writing a Terraform Provider for Octopus Deploy (and the GoLang SDK for it).
I would love some feedback, feature suggestions or even some people to help out.
Currently, you can create Projects, Project Groups and Deployment Steps inside the projects.
* Terraform Provider - https://github.com/MattHodge/terraform-provider-octopusdeploy
* Octopus Deploy Golang SDK - https://github.com/MattHodge/go-octopusdeploy -
Jeremy Gaither
commented
I'd really like to see a Terraform provider for Octopus Deploy!
-
Andrew Ogburn
commented
We're moving toward all infrastructure & pipeline as code, so this would be very helpful! Eventually not having feature could lead us to using GitLab for CI & CD instead of Octopus, which would be a sad day!
-
Jesper Balle
commented
Good suggestion to use a declarative approach outside of Octopus and good examples of using this, considerations if you should put the octopus declarative configuration in same repository with your application code and update octopus through each build or have a separate repostory for the octopus process, what are the pros and cons.
Terraform provider could be nice because there are some existing documentation but I don't if the different concepts would make it too hard to actually win the benefit. -
Asbjørn Ulsberg
commented
Why reinvent the wheel? Just add a Terraform provider for Octopus Deploy and be done with it. The proposed "declarative" way to do it is overly cumbersome and has NIH written all over it.
-
Benjamin Goldman
commented
So I get really fidgety whenever we have tools for anything automation-ish that do not come with their own DSL or something similar. Getting CLOSER to that is a BIG DEAL and will make the non Microsoft shops take this platform seriously...
-
Craig Shea
commented
This would be a great addition to OD. As mentioned in the OP, the current import/export tool is less than desirable for versioning OD scripts, especially those that are part of Script Step Templates (as opposed to those included in OctoPack NuGet packages).
-
Tom Langeraet
commented
Adding "PreDeploy.ps1", "Deploy.ps1" or "PostDeploy.ps1" scripts to your NuGet package will trigger the Octopus built-in hooks and execute your custom scripts, which you can store in source control ...
-
Chris Camburn
commented
Even with octo.exe export for deployment processes, that doesn't provide the ability to recreate the entire server. TeamCity has direct source control integration, so that in the event that something should happen to my server, I can link a new install to source control and recover every bit of configuration.
The other two (smaller) advantages of this are the ability to edit configuration outside of the UI by making changes directly in source control, and the ability to accurately track all changes made. The audit log in Octopus is difficult to use when tracking small changes to a deployment process. Source control integration would make this simple.
-
Jose Dominguez
commented
This would be great. What I've done in the past to circumvent this is add my powershell script as a project file and call the file from octopus like (invoke-expression -command)
-
jez lloyd
commented
We really need integration with source control, preferably github please. I'm being asked questions as to why use Octopus when it doesn't integrate with our source control.
-
Blair Paine
commented
Scripts, configuration, variables, every input should be able to be stored in source control and fully audited i.e. GIT. We're looking to integrate with etcd or consol to obtain key/value pairs of variable information from JSON/YAML configs in GIT and share across all of our pipeline via the API. If anyone changes a configuration we'll know when it was changed and who changed it and for what reason.
I don't want my variables and configuration data for an entire pipeline tied to just Octopus. Octopus is a key part of our delivery pipeline but I don't believe it should own the inputs to make it work.
Voted up after posting here:
http://help.octopusdeploy.com/discussions/questions/9658-anyone-using-git-and-consul-with-od -
Zachary Sims
commented
Jenkins has recently gone down this path. The (plugin) idea spawned out of Netflix: https://wiki.jenkins-ci.org/display/JENKINS/Job+DSL+Plugin
Basically it supports describing everything + scripts + whatever.
-
Micheal Schexnayder
commented
Along these lines, I think the needed functionality is being able to select the version of a step template to use as a part of a deployment process. This becomes important when you have many jobs using a step template and rollout of the changes can't be a "one-and-done" approach.
This idea has really forced us to re-evaluate how modifications to step templates occur on our systems; not just from a development standpoint but an impact to our customers standpoint. Essentially we've moved to a model where we artificially version the step templates with a version embedded in the name:
- My Template (v1.0)
- My Template (v1.1)
In this model step templates become immutable (except to fix bugs). New features are added as a new version of the template, there by not disturbing those who are using the older versions but making the new one available to those who want/need to use it. -
Managing step templates versions should be included in this.
Source: http://help.octopusdeploy.com/discussions/questions/9234
-
Alexandra Carter
commented
As we create more and more pipelines using Octopus and explore deeper levels of complexity, the need for this is increasing. We would be very grateful to have a good way of managing our scripts in source control and then pushing or pulling latest versions into Octopus.
-
Daniel Robertson
commented
I've been wondering how to best implement something like this as we have so many step templates and a fair few step modules. Having this in proper source control should be essential.
-
Dru Sellers
commented
Yes please. I'm thinking it would be a library source in Octo where I could point it at a GitHub repository and i could either trigger imports from GitHub - it could warn me of version changes, etc. That way devs can iterate on the PS scripts in Github and then when they are ready could merge to master and then pull them into Octo.