Practice: Version Control Your Configuration

capabilities/deployment-automation.md

@@ -53,7 +53,7 @@ Develop scripts that automate the entire deployment process, including environme
 
 Use Infrastructure as Code (IaC) tools to define and manage your infrastructure through code rather than manual processes. Tools like [Terraform](https://github.com/hashicorp/terraform) or [Pulumi](https://github.com/pulumi/) allow you to version control your infrastructure configurations and provision environments automatically. Embracing IaC ensures environments are consistent and can be re-created reliably, which enhances deployment automation and reduces configuration drift.
 
-### Store Configuration in Its Own Repository
+### Version Control Your Configuration
 
 Keep all deployment scripts and configuration files in version control systems like Git. This practice allows teams to collaborate more efficiently, audit changes, and roll back to previous configurations if needed. Storing configurations in version control increases transparency and control over the deployment process, making it more manageable and secure.
 

capabilities/version-control.md

@@ -61,11 +61,7 @@ The following is a curated list of supporting practices to consider when looking
 
 Implementing automatic database migrations ensures database schema changes are consistently versioned and managed alongside application code. This practice fosters an environment where code and database changes are integrated, tested, and deployed in a unified manner. The result is more reliable development workflows and an added layer of automation and traceability to database evolution.
 
-### [Automate Deployment Scripts](/practices/automate-deployment-scripts.md)
-
-Automating deployment scripts ensures the steps required to release software are explicitly defined, repeatable, and versioned alongside the rest of the system. This practice reduces manual error, improves reproducibility across environments, and makes it easier to trace, audit, and roll back deployments when issues arise.
-
-### [Separate Config from Code](/practices/separate-config-from-code.md)
+### [Decouple Configuration from Code](/practices/decouple-configuration-from-code.md)
 
 This practice separates application code from operational configurations, which enhances security and deployment processes. It minimizes risks associated with data exposure, focusing version control efforts on code changes.
 

practices/separate-config-from-code.md → practices/decouple-configuration-from-code.md

@@ -1,19 +1,23 @@
-# Separate Config from Code
+# Decouple Configuration from Code
 
 Separating configuration from code is crucial for maintaining secure and flexible systems. Extracting configurable values makes systems adaptable, enabling easy adjustments without modifying the codebase. Sensitive information like passwords or API keys should be isolated to limit access to highly trusted team members.
 
 ## Nuance
 
 ### Configuration Storage
+
 Store sensitive configurations in secure, encrypted repositories or vaults, enforce strict access controls and conduct regular security audits. When considering storing options, favor ones that support versioning configuration changes so you retain the ability to restore to previous "known to work" configuration values.
 
 ### Deployment Complexity
+
 Adopting external configuration management introduces complexity in selecting and implementing the right tools and processes. Teams must navigate through options, considering factors such as integration, security, and scalability, to find a balance between the benefits of externalized configurations and the added complexity of managing them effectively.
 
 ### Environment Parity
+
 Use the same environment variables, configuration files, and services to ensure uniformity from development through production, thereby reducing deployment errors and operational discrepancies. Obviously the configured values will differ from environment to environment. The key consideration here is to maintain an identical "configuration schema" so to speak.
 
 ### Allow Local Overrides
+
 Allow local overrides of configuration values and provide developers with a blueprint to create their own local configuration files. For instance, an .env.example file might include placeholders for environment variables that need to be set but without providing any real keys or passwords. This keeps sensitive data out of application version control, without constraining developer productivity.
 
 ## How to Improve
@@ -71,13 +75,17 @@ How do we strike a balance between the flexibility of externalized configuration
 ## Supporting Capabilities
 
 ## [Version Control](/capabilities/version-control.md)
+
 By advocating for the exclusion of configuration and sensitive data from version control, this practice improves the Version Control Capability, by defining the exceptions where storing information in application code source control is not desirable.
 
 ## [Continuous Integration](https://dora.dev/devops-capabilities/technical/continuous-integration)
+
 Separate Config from Code facilitates more efficient and secure continuous integration (CI) processes. It allows for seamless integration of code changes by ensuring that environment-specific configurations do not interfere with the build process, thereby enhancing the reliability and speed of CI cycles.
 
 ## [Deployment Automation](https://dora.dev/devops-capabilities/technical/deployment-automation)
+
 This practice necessitates sophisticated deployment automation that can manage and inject external configurations at deployment time. By separating configuration from the codebase, deployment automation becomes a critical capability for applying different configurations across environments automatically, thus supporting scalable and repeatable deployments.
 
 ## [Monitoring and Observability](https://dora.dev/devops-capabilities/technical/monitoring-and-observability)
+
 While not directly related to monitoring and observability, this practice indirectly supports these capabilities by promoting cleaner and more manageable codebases. By keeping configuration data separate, it simplifies the application's operational landscape, making it easier to monitor and observe its behavior across different environments.

practices/version-control-your-configuration.md

@@ -0,0 +1,21 @@
+# Version Control Your Configuration
+
+It’s often useful to separate application code, which defines behavior, from configuration, which adapts that behavior to a specific environment. By storing configuration files—such as environment variables, feature flags, and infrastructure definitions in a dedicated version control repository, teams create a "single source of truth" for the state of their systems. This practice, often referred to as the backbone of GitOps, allows operations and development teams to manage environment changes with the same rigor used for software development.
+
+Decoupling configuration from application source code significantly improves the safety and speed of deployments. When configuration is embedded in the application build artifact, changing a simple setting requires a full rebuild and redeploy of the binary. By isolating configuration in its own repository, teams can modify environment settings dynamically or trigger specific configuration-update pipelines. This separation also simplifies auditing, as the commit history of the configuration repository provides a clear timeline of who changed a setting, what was changed, and when it occurred.
+
+Furthermore, this practice enhances security and stability across different environments (Dev, Stage, Prod). It prevents the "it works on my machine" syndrome by ensuring that the configuration applied to an environment is explicitly defined in code, rather than manually tweaked on a server. It also allows for granular access control; while many developers may contribute to the application source code, a smaller, more specialized group might hold write access to the production configuration repository, ensuring that critical operational changes are peer-reviewed before being applied.
+
+## Supported Capabilities
+
+### [Version Control](/capabilities/version-control.md)
+
+This practice extends the benefits of version control beyond application source code to the infrastructure and operational settings of the system. By keeping configuration in Git, teams gain immediate access to branching strategies, pull request reviews for config changes, and the ability to instantly roll back to a previous known-good state if a configuration change causes an outage.
+
+### [Deployment Automation](/capabilities/deployment-automation.md)
+
+Storing configuration externally is a prerequisite for fully automated deployment pipelines. Automation tools can programmatically pull the specific configuration required for a target environment at runtime, ensuring that deployments are repeatable and removing the need for manual intervention or error-prone "hot fixes" on live servers.
+
+### [Pervasive Security](/capabilities/pervasive-security.md)
+
+Isolating configuration allows teams to implement stricter governance and security policies regarding who can modify the runtime behavior of production systems. It creates an immutable audit trail for compliance purposes and allows for the automated scanning of configuration files to detect secrets, keys, or insecure settings before they are ever applied to the infrastructure.