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.

@Michael Noonan, any update regards the terraform provider? It still seems to be early in the development and the documentation is quite lacking.

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

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.

https://octopus.com/docs/deployment-patterns/deployment-process-as-code

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)

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.

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.

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

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.

I'd really like to see a Terraform provider for Octopus Deploy!

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.

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!

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.

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.

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.

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.

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.