The Configuration as Code (config-as-code) feature adds support for configuring Octopus projects to store project resources in a Git repository. For now, only the deployment process, deployment settings, and non-sensitive variables can be version-controlled.
The Octopus UI needed to remain fully functional for version-controlled projects, and it has. You can continue to use the UI exactly as you always have, but with an additional superpower: Git branches are now exposed in the UI, allowing editing of currently supported project configuration on any branch via the UI. If you type the name of a branch that doesn't exist in your repository, you'll see an option to create that branch. This option is available when committing changes too.
Of course, there is now a text representation of the process in the Git repository, and if you prefer editing text, open your favorite editor and go for it. We refer to the text format as Octopus Configuration Language (OCL), and it is very much inspired by HCL.
That means that where previously there was only a single current version of the deployment process, it is now possible to have many. When creating releases, the relevant branch can be selected. We have also added branch system variables that can be used in your custom deployment scripts.
Config-as-code only supports git repositories. Before using this feature, you should be familiar with git concepts such as distributed version control, pushing, pulling, branching, merging, and fetching.
We have some strong opinions on what's next. The latest release of config-as-code supports deployment processes, deployment settings, and non-sensitive variables.
We have plans for future releases of config-as-code to support Runbooks. In addition, we'd like to evolve the OCL schema to make it friendlier for editing by hand.
We want your feedback
Our major goal for the early stages of this feature is to discover the ways people want config-as-code to evolve. What scenarios would you like to see unlocked? What doesn't work the way you hoped?
You can provide feedback through whichever of the following channels you feel most comfortable with:
- Feedback form. There is a link in a version-controlled project's Version Control Settings section that takes you to a feedback form when clicked. This is a great way to provide structured feedback.
- Community slack. The
config-as-codechannel in the Octopus community slack is the best place to have a conversation with the team.
- Support. For errors or issues, see our official support channels.
Configuring a project to be version-controlled
Version-control is configured per project and is accessed via the Settings ➜ Version Control navigation menu item.
Learn more about Configuring version control on a project.
Several resources previously stored in SQL Server will now be stored in git once a project is version-controlled.
Learn more about Configuration as Code reference
Making changes to a version-controlled project
Any changes to the deployment process or settings are made on a branch after a project is configured to be version-controlled.
Learn more about Editing a project with version control enabled.
Migrating projects to support new features
Since the initial public release of config-as-code, we've added support for additional project configuration in Git. Learn more about migrating variables to Git
Creating and deploying releases
Once an Octopus project is configured to be version-controlled, you can choose which branch to build from before creating a release in Octopus.
Learn more about creating and deploying releases in a version controlled project.
The Configuration as Code feature is designed to give you the benefits of source control, branching, reverting, and pull requests while being able to use your tool of choice to manage your processes (and eventually) variables. While it has many benefits, there are some unsuitable use cases and scenarios.
Learn more about unsupported config-as-code scenarios
Need support? We're here to help.