Configuration files

Conventions

Default configuration path

By default PoshArm-Deployment will look in the current script folder for configuration files. You can override this behavior by setting the ConfigurationPath argument on Publish-ArmResourceGroup

Default configuration file pattern

The default convention for configuration file name is ScriptConfiguration.json ScriptConfiguration.[env].json

Configuration template

{
  "projectName": "<YOUR PROJECT NAME HERE>",
  "location": "<AZURE LOCATION>",
  "environmentCode": "<PUT YOUR ENV CODE HERE>",
  "context": "<Context>",
  "version": "1.0",
  "properties": {}
}

ProjectName

Represents the project name or project code name. This value is use in the default convention to generate resource and resource group names

Location

Location where to deploy the resources i.e. EastUS

EnvironmentCode

Code of the environment where you are deploying. i.e. Dev, QA, Staging, Prod, etc...

Context

Context is a value that is optional and will be used in resource name is defined. This value can be use for many different purposes. The idea is to add some context. i.e. If you use DDD this could represent the name of a bounded-context.

Version

Version is part of the hash that is appended on every resource name. This behavior is intended to enable blue/green deployment. Changing the version number will effectively create new resource names and enable you to deploy resources side by side before switching to the new resources.

Properties

This is where you can add you custom configuration values.

Configuration per environment

Configuration files are hierarchical, meaning ScriptConfiguration.json is loaded first and then ScriptConfiguration.[env].json is loaded on top of it overriding values when needed. Lastly, ScriptConfiguration.[env].override.json is loaded on top of everything. This means, every settings that is shared between all environments should be put in ScriptConfiguration.json and then only overrides needs to be added to ScriptConfiguration.[env].json files which reduce greatly the repetition of values between configuration and makes it way more intuitive to maintain.

Local configuration per user

Another common scenario is to have configuration per developer. To enable this you'll need to use the .override syntax. i.e. ScriptConfiguration.[env].override.json It's also important that you add an exclusion for .override files in you .gitignore file

*.override.json

This will make sure that ScriptConfiguration.[env].override.json is never push to your git repository and that every developer can override their own settings if needed without impacting the others.