Update references from "Configure as Code" to "Version Control"

.github/CODEOWNERS

@@ -99,7 +99,7 @@
 
 /docs/projects/coordinating-multiple-projects/ @OctopusDeploy/team-support
 
-# updates to the config as code section are reviewed by team-modern-deployments
+# updates to the version control section are reviewed by team-modern-deployments
 
 /docs/projects/version-control/ @OctopusDeploy/team-devex
 

src/pages/docs/administration/data/data-migration.md

@@ -1,7 +1,7 @@
 ---
 layout: src/layouts/Default.astro
 pubDate: 2023-01-01
-modDate: 2024-07-15
+modDate: 2025-05-13
 title: Data Migration
 description: Octopus comes with a data migrator that can help with specific scenarios, such as exporting configuration for storage and audit and single-direction copying of projects from one Octopus Server to another.
 navOrder: 30
@@ -31,7 +31,7 @@ The data migration tools are only suitable for some scenarios. In most cases, th
 1. To split a single Octopus Server into multiple separate Octopus Servers in a one-time operation, use the [Export/Import Projects feature](/docs/projects/export-import).
 1. To sync projects with disparate environments, tenants, lifecycles, channels, variable values, or deployment process steps, see [syncing multiple instances](/docs/administration/sync-instances)
 1. To consolidate multiple Octopus Servers into a single Octopus Server, use the [Export/Import Projects feature](/docs/projects/export-import).
-1. To audit your project configuration, see [configuration as code](/docs/projects/version-control).
+1. To audit your project configuration, see [version control](/docs/projects/version-control).
 1. To split a single space into multiple spaces, see the [Export/Import Projects feature](/docs/projects/export-import).
 1. To migrate data from older versions of Octopus see [upgrading old versions of Octopus](/docs/administration/upgrading/legacy).
 1. For general disaster recovery, learn about [backup and restore for your Octopus Server](/docs/administration/data/backup-and-restore).

src/pages/docs/administration/migrate-spaces-with-octoterra/index.md

@@ -1,7 +1,7 @@
 ---
 layout: src/layouts/Default.astro
 pubDate: 2099-01-01
-modDate: 2099-01-01
+modDate: 2025-05-13
 title: Migrating spaces with Octoterra
 description: How to migrate spaces using the octoterra tool
 navOrder: 100
@@ -28,7 +28,7 @@ The [Import/Export tool](https://octopus.com/docs/projects/export-import) is bui
 
 Typically, you would choose the Import/Export tool to perform a migration. However, there are cases where the Import/Export tool is not suitable:
 
-* You wish to migrate Config-as-Code (CaC) projects, as the Import/Export tool does not support CaC projects.
+* You wish to migrate version control enabled projects, as the Import/Export tool does not support version control enabled projects.
 * You wish to recreate targets, as the Import/Export tool does not migrate targets.
 * You wish to "own" or modify the intermediate format used for the migration, as the Import/Export tool uses an undocumented JSON format.
 
@@ -56,13 +56,13 @@ Octoterra will display an error like this when an unsupported step is encountere
 Action <step name> has the "Items" property, which indicates that it is from the new step framework. These steps are not supported and are not exported.
 ```
 
-### Config-as-Code (CaC) repositories
+### Version control enabled projects
 
-Octoterra converts CaC projects back to regular projects as part of the migration. The project can be converted back to CaC on the destination space once the migration is complete.
+Octoterra converts version control enabled projects back to regular projects as part of the migration. The project can be converted back to version control on the destination space once the migration is complete.
 
-However, be aware that Octopus does not support sharing project CaC configuration between two projects. You are prevented from doing so with multiple CaC projects on a single Octopus instance. While you are not prevented from configuring two projects against a shared CaC project configuration from multiple Octopus instances, there are cases where the CaC configuration references space specific resource IDs, such as step templates, which have unique (and incompatible) IDs across spaces and instances. This means you can not assume you can configure a new project in a new space or on a new instance against an existing project CaC configuration hosted in Git.
+However, be aware that Octopus does not support sharing project configuration between two projects. You are prevented from doing so with multiple version control enabled projects on a single Octopus instance. While you are not prevented from configuring two projects against a shared version control enabled project configuration from multiple Octopus instances, there are cases where the configuration references space specific resource IDs, such as step templates, which have unique (and incompatible) IDs across spaces and instances. This means you can not assume you can configure a new project in a new space or on a new instance against an existing project configuration hosted in Git.
 
-The recommended solution is to convert the projects in the destination space to a new directory or Git repository. This ensures that the new projects have valid CaC configuration.
+The recommended solution is to convert the projects in the destination space to a new directory or Git repository. This ensures that the new projects have valid configuration.
 
 ### Other settings
 
@@ -318,12 +318,12 @@ A number of sensitive values can not be migrated by Octoterra including:
 
 All these values must be manually reconfigured on the destination server.
 
-### Convert projects back to CaC
+### Convert projects back to version control
 
-CaC projects are converted back to regular projects during the migration. These projects must be manually converted back to CaC on the destination server.
+Version control enabled projects are converted back to regular projects during the migration. These projects must be manually converted back to version control on the destination server.
 
 :::div{.warning}
-You can not assume that you can point the projects back to their original configuration stored in Git. Values like step template IDs are hard coded in CaC configuration but are different between servers. Octopus also does not support pointing two projects to the same directory in a Git repository, so the source and destination servers can not reference the same Git repository and directory at the same time.
+You can not assume that you can point the projects back to their original configuration stored in Git. Values like step template IDs are hard coded in configuration but are different between servers. Octopus also does not support pointing two projects to the same directory in a Git repository, so the source and destination servers can not reference the same Git repository and directory at the same time.
 :::
 
 ### Migrate packages from built-in feed

src/pages/docs/administration/private-cloud-migration/index.md

@@ -1,7 +1,7 @@
 ---
 layout: src/layouts/Default.astro
 pubDate: 2023-01-01
-modDate: 2023-01-01
+modDate: 2025-05-13
 title: Private cloud migration
 description: Guidelines for migrating an on-premises Octopus instance to private cloud hosting
 navOrder: 55
@@ -177,7 +177,7 @@ Choose an incremental migration when:
 An incremental migration may not suitable when:
 
 * You require the complete audit history to be present on the cloud instance, as the export/import feature does not migrate audit events.
-* You have a large number of Config-as-Code enabled projects, as the export/import feature does not export these projects.
+* You have a large number of version control enabled projects, as the export/import feature does not export these projects.
 * You do not wish to reregister listening tentacles, as the new cloud instance has new certificates and will not be able to establish a connection to existing listening tentacles.
 * You have a large number of project triggers, as the export/import feature does not export triggers.
 * You have a large number of users and teams in the internal Octopus database, as these will have to be manually recreated.

src/pages/docs/administration/sync-instances/index.md

@@ -1,7 +1,7 @@
 ---
 layout: src/layouts/Default.astro
 pubDate: 2023-01-01
-modDate: 2023-10-04
+modDate: 2025-05-13
 title: Sync multiple instances
 description: How to keep two or more Octopus Deploy instances in sync.
 navOrder: 45
@@ -48,7 +48,7 @@ In talking to users, the primary reason for splitting an instance is due to perm
 - Release managers can modify the variables on a set of tenants assigned to them.  All other tenants are read-only.
 
 ### Approval process
-Another reason we hear about is needing an approval process for changes to the deployment process.  Please see our [config as code feature](/docs/projects/version-control) as that integrates with git, which allows for branching and pull requests.  
+Another reason we hear about is needing an approval process for changes to the deployment process.  Please see our [version control feature](/docs/projects/version-control) as that integrates with git, which allows for branching and pull requests.  
 
 ### Performance improvement
 The final reason we hear about is to "speed up the deployment."  Typically we hear this when Octopus is located in one data center and deployment targets are located in a data center in another country or continent.  That can lead to long package acquisition from the built-in repository and latency.
@@ -62,7 +62,7 @@ The final reason we hear about is to "speed up the deployment."  Typically we he
 
 Do not split an instance and sync it for any of the following use cases.
 
-- You want an approval process for any changes to your deployment process.  Please see our [config as code feature](/docs/projects/version-control) as that integrates with git.
+- You want an approval process for any changes to your deployment process.  Please see our [version control feature](/docs/projects/version-control) as that integrates with git.
 - You want to move a project from the default space to another space on the same instance (or different instance).  Please see our documentation on our [Export/Import Projects feature](/docs/projects/export-import).
 - You want to create a test instance to test out upgrades or try out new processes.  Please see our guide on [creating a test instance](/docs/administration/upgrading/guide/creating-test-instance)
 - You want to upgrade the underlying VM hosting Octopus Deploy from Windows Server 2012 to Windows Server 2019.  Please see our guide on [moving the Octopus Server](/docs/administration/managing-infrastructure/moving-your-octopus/move-the-server).
@@ -90,9 +90,9 @@ The Migrator and Export/Import Project feature can be run multiple times for the
 
 The [Octopus CLI](/docs/octopus-rest-api/octopus-cli/) includes the [export](/docs/octopus-rest-api/octopus-cli/export/) and [import](/docs/octopus-rest-api/octopus-cli/import) commands.  Those commands are deprecated and should not be used.  
 
-### Config as Code and Octopus Terraform Provider
+### Version Control and Octopus Terraform Provider
 
-Terraform uses Hashicorp Configuration Language or HCL.  The [Config as Code feature](/docs/projects/version-control) uses Octopus Configuration Language (OCL) and that is based on HCL.  HCL does not support complex logic.  That means you'd need a unique set of files per instance.  To sync instances using these features, you'd need to use a comparison tool such as Beyond Compare to move changes between instances manually.  Anything manual is error-prone and will eventually fail. 
+Terraform uses Hashicorp Configuration Language or HCL.  The [version control feature](/docs/projects/version-control) uses Octopus Configuration Language (OCL) and that is based on HCL.  HCL does not support complex logic.  That means you'd need a unique set of files per instance.  To sync instances using these features, you'd need to use a comparison tool such as Beyond Compare to move changes between instances manually.  Anything manual is error-prone and will eventually fail. 
 
 You can write a tool to compare files between instances automatically and make the necessary modifications.  You will run into the a lot of the same roadblocks as below as you'll need to consider dependencies, environment mis-matches, and more.  
 

src/pages/docs/best-practices/deployments/projects-and-project-groups.md

@@ -1,7 +1,7 @@
 ---
 layout: src/layouts/Default.astro
 pubDate: 2023-01-01
-modDate: 2023-10-04
+modDate: 2025-05-13
 title: Projects and Project Groups Structure
 description: Guidelines and recommendations for configuring projects and project groups in Octopus Deploy.
 navOrder: 50
@@ -29,7 +29,7 @@ All the components in a single "solution" or built in the same configuration sho
 If you want to have a project per component, you need to ensure each component is decoupled from one another and can be deployed on a separate schedule.  
 
 :::div{.hint}
-Previous versions of this guide recommended having a project per component.  Octopus Deploy now includes new features, including ITSM integration, Config as Code, and more options for variable run conditions.  There is also a logistical overhead with a project per component.  That recommendation was made in 2021.  At that time, a project per component made sense.  It is no longer applicable with the 2023 version of Octopus Deploy.
+Previous versions of this guide recommended having a project per component.  Octopus Deploy now includes new features, including ITSM integration, version control, and more options for variable run conditions.  There is also a logistical overhead with a project per component.  That recommendation was made in 2021.  At that time, a project per component made sense.  It is no longer applicable with the 2023 version of Octopus Deploy.
 :::
 
 ## Anti-patterns to avoid

src/pages/docs/deployments/custom-scripts/run-a-script-step.md

@@ -1,7 +1,7 @@
 ---
 layout: src/layouts/Default.astro
 pubDate: 2023-01-01
-modDate: 2024-08-27
+modDate: 2025-05-13
 title: Run a script step
 description: Standalone scripts allow you to run scripts contained in a package, in a git repository, or ad-hoc scripts you've saved as part of the step.
 icon: fa-regular fa-file-code
@@ -58,7 +58,7 @@ Using scripts from inside a package or a git repository are a great way to versi
 :::
 
 :::div{.hint}
-If you are storing your project configuration in a Git repository using the [Configuration as code feature](/docs/projects/version-control), you can source files from the same Git repository as your deployment process by selecting Project as the Git repository source. When creating a Release, the commit hash used for your deployment process will also be used to source the files.
+If you are storing your project configuration in a Git repository using the [version control feature](/docs/projects/version-control), you can source files from the same Git repository as your deployment process by selecting Project as the Git repository source. When creating a Release, the commit hash used for your deployment process will also be used to source the files.
 
 You can find more information about this feature in this [blog post on using Git resources directly in deployments](https://octopus.com/blog/git-resources-in-deployments).
 :::

src/pages/docs/deployments/patterns/deployment-process-as-code.md

@@ -1,15 +1,15 @@
 ---
 layout: src/layouts/Default.astro
 pubDate: 2023-01-01
-modDate: 2023-01-01
+modDate: 2025-05-13
 title: Deployment process as code
 description: With Octopus you can manage your deployment process as code. This means you can define your deployment process, scripts, and variables in source code. You can store this configuration in the same source control repository as your application source code, or somewhere else. This page describes the different options available in Octopus to store your deployment process as code.
 navOrder: 70
 ---
 
 :::div{.hint}
-**Looking for Configuration as Code?**
-This section looks at storing your deployment process as code **without** using the [Configuration as Code](/docs/projects/version-control) feature.
+**Looking for Version Control?**
+This section looks at storing your deployment process as code **without** using the [Version Control](/docs/projects/version-control) feature.
 :::
 
 With Octopus you can manage your deployment process as code. This means you can define your deployment process, scripts, and variables in source code. You can store this configuration in the same source control repository as your application source code, or somewhere else.
@@ -66,7 +66,7 @@ Follow this process to move your Octopus project configuration to code:
 
 1. Move your [deployment scripts to code](#scripts-as-code) and decide if you want to take this next step.
 1. Convert your project configuration to code: learn about [configuring Octopus using code](#configure-octopus-using-code).
-1. Test your project configuration as code, targeting a dummy project so your real project continues to work uninterrupted.
+1. Test your project configuration, targeting a dummy project so your real project continues to work uninterrupted.
 1. When you are happy with your testing, update your build pipeline to target the real project.
 1. Train your people to make changes safely using **project as code**.
 
@@ -82,15 +82,13 @@ The process flow of using **project as code** looks similar to what you already
 
 ### Configure Octopus using code {#configure-octopus-using-code}
 
-Octopus has a comprehensive HTTP API and .NET SDK you can use to automate **everything** in Octopus. If you can do something through the user interface, you can automate it with code. You can create and update projects, variables, deployment processes, and more. A downside of this approach is how much work is involved: you need to write code that detects drift and applies deltas, or is idempotent. Today, this is our only fully-supported solution to define your Octopus configuration as code.
+Octopus has a comprehensive HTTP API and .NET SDK you can use to automate **everything** in Octopus. If you can do something through the user interface, you can automate it with code. You can create and update projects, variables, deployment processes, and more. A downside of this approach is how much work is involved: you need to write code that detects drift and applies deltas, or is idempotent.
 
 There is an [open source Terraform provider for Octopus](https://github.com/OctopusDeploy/terraform-provider-octopusdeploy), which is built on top of the Octopus HTTP API. The Terraform provider for Octopus detects drift and applies deltas. We are using this Terraform provider ourselves for [Octopus Cloud](https://octopus.com/cloud) (our SaaS product), and we are actively contributing to the provider. It doesn't cover 100% of all Octopus features yet, and the structure of the Terraform resources are subject to change. We will be building first-class support for this into the Octopus ecosystem in the future.
 
-If you want to do **Octopus configuration as code** today, we recommend using our .NET SDK which will always be supported. The Terraform provider will be a simpler, more declarative approach, that we will support in the future.
-
 ### Consistency and repeatability using project as code
 
-When managing your Octopus configuration as code, Octopus still makes sure your deployments are consistent and repeatable. Whenever you push a configuration change to your Octopus project via code, it's just like people using the user interface or API to make changes. When you create a release, Octopus takes a snapshot of the deployment process, variables, and packages making every deployment of that release consistent and repeatable, regardless of whether the project was configured by a person or by code.
+When managing your Octopus configuration, Octopus still makes sure your deployments are consistent and repeatable. Whenever you push a configuration change to your Octopus project via code, it's just like people using the user interface or API to make changes. When you create a release, Octopus takes a snapshot of the deployment process, variables, and packages making every deployment of that release consistent and repeatable, regardless of whether the project was configured by a person or by code.
 
 This means you can push configuration changes to Octopus as code, and get the same consistent and repeatable experience you expect for your deployments.