Configuration Variables
IT products are littered with configuration, but powerdelivery is only concerned with those that change from one environment to another. For example, the name of the database in a test environment might be different than in production.
To point to the correct resources during each release without resorting to manual changes, you will record these using variables in PowerShell scripts within the Configuration directory of your powerdelivery project. Configuration variable scripts must return a hash. The values of the variables can be strings, integers, other hashes, or whatever you want to make available to roles that apply actual changes to nodes in the environment.
Shared variables
Every powerdelivery project includes one required variable script named _Shared.ps1. This script contains configuration variables that are available to all environments.
Below is an example. The keys and values here are simply for demonstration purposes.
You’ll notice a $target parameter in the script. This can be used to reference secrets or other properties of the current run of the deployment to use in shared configuration variables.
Environment-specific variables
For every environment in your powerdelivery project, you must have a script named the same as the environment in the Configuration directory. If you define variables with the same name as those that exist in Shared.ps1, these will be overridden by the environment-specific definition at deployment time.
Environment-specific variable scripts declare the $shared parameter in addition to $target (which is present in the shared configuration script). Powerdelivery will pass the shared configuration variables hash as this parameter, allowing you to reference them.
Below is an example of the configuration variable script for an environment named Staging.
Tips
- You can write PowerShell code above the hash to generate variables at runtime.
- You must ensure any role that expects a variable has it defined as a shared variable, or in all environments.