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."
Now available in early access preview, with general availability coming soon.
It worth noting that you can achieve this outcome without Octopus features. The deployment logic really should be scripted and controlled directly with the application, it should not be separated at all, evolving in lock step with it on the same branches. We do this, and have only ever used Octopus as a layer over the top, that calls those native installers we include in our apps, and allowing additional orchestration to handle multi server environments. This installation logic is a deliverable from the dev team, and testable by them, before Octopus enters the picture.
Bartek J. commented
@Michael Noonan, any update regards the terraform provider? It still seems to be early in the development and the documentation is quite lacking.
Andrea Maruccia commented
is this available? will do a software selection for k8s deployment tools but pipeline as code is a requirement
I think this is crucial in order to compete with products like azure devops which now has multistage builds
Michael Noonan commented
Hi All. A full end-to-end story is getting closer: we have officially adopted the Terraform Provider for Octopus: https://github.com/OctopusDeploy/terraform-provider-octopusdeploy
Just in case this is news: You can already manage the most complex and most important parts of your deployment process - your custom scripts. We've written a comprehensive guide to managing your Octopus configuration as code, including the different options available today along with their problems, and will update the page as we improve this story.
Our first stop along the way should look something like this:
- You will be able to export all or part of your project to a Terraform template so you can get started, or see how to make changes to your template
- You will be able to use the Terraform Provider for Octopus to manage your project as code
We still have quite a few decisions to make, but hopefully this provides everyone with some context on how we want to approach the problem so you can provide feedback as a comment in this suggestion:
- Read the documentation page to understand how we think about this problem today
- Imagine how your dream process would look with Terraform in the mix
- Post a comment here describing the workflow you want to see (including your branching strategy)
Rob Barnes commented
Is this any closer to a reality?
Developers, especially dotnet devs are quite comfortable with Octopus so when choosing my tooling for a project, Octopus is always a real consideration; however, without pipeline as code approach, allowing our pipelines to be version controlled, I struggle to justify picking this tool over other competitors.
More and more teams are moving to a GitOps way of working so having all elements described in a declarative way to allow Git to be the source of truth is a key factor and right now, Octopus isn't capable of that, which is disappointing really.
Pipeline as Code would be awesome for Octopus - one of the main advantages of VSTS/ Az DevOps over it atm, I think. Especially if it could be for both build and release pipelines.
Jasper Nygaard commented
From the speaskers at WinOps London 2018, I got a notion that they actually have an internal Terraform provider for Octopus, but it wasn't meant for public release. When pitching Octopus Deploy in public, this is really one of the few drawbacks of this product. Everything should be in source control...
It would be great to have this feature.
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
Bob Hardister commented
For me, the request is more basic: "Octopus as code" or "OAC." TeamCity now provides this, and we are doing this with our product infrastructure in Kubernetes.
Jeremy Gaither commented
I'd really like to see a Terraform provider for Octopus Deploy!
Aaron Roydhouse commented
Steve, YAML would be the scaffolding, but there would be no reason that the fields couldn't include whole bash/C#/PowerShell scripts. YAML fields support here-docs so including a small or large script is no problem. That way your pipeline could have Powershell for one step and then bash for another, as appropriate.
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!
Steve Sherwood commented
I like this idea, but please not YAML. We can use bash,C#,Powershell for scripts and modules - Lets have the same choice of languages for pipeline as code.
elad kirmayer commented
This is impotent. We want to use the Octopus Deploy to site we have which are behind firewalls and we cant access them. we need to be able to easily share the flow and allow each changes while keeping view able track on the changes.
Anders Lundsgard commented
I think this one is crucial. Wen the agile teams at my work currently start to realise the beauty of versioning their pipe as code (GitLab CI) Octopus start to fall short because of all web ui clicking to make a single pipe.
I would like to see the "pipeline as code approach" applied to projects. The main idea is to be possible to define the process of a project using a yml file in a source code repository or package.
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.