Deployment Pipeline as Code
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.
We like this idea too.
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.
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.
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.
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.