Layering Basics
Basics
Layering generally works the same for params and variables files. They use different folders. Example:
config/blueprints/demo/params
config/blueprints/demo/vars
Params have a .env
extension, and vars have a .rb
extension. We’ll show a params example to cover the basics of layering.
config/blueprints/demo/params
├── base.env
├── dev.env
└── prod.env
base.env
is always evaluated.dev.env
orprod.env
is evaluated based onLONO_ENV
.
In this case, you want to define your base params used for templates in the base.env
and overrides in prod.env
.
The basic example above shows layering with the top-level config
folder. You can also define layers within the blueprint.
Separate Layers
You can have your layer files defined in the blueprint itself or at the project level. Example:
- Blueprint Layers: These layers ship with the blueprint. Think of them as defaults that ship with the blueprint itself. IE:
app/blueprints/demo/config
. These layers are processed first and take lower precedence. - Project Layers: These layers are your project-specific settings. IE:
config/blueprints/demo
. These layers are processed later and take higher precedence. They override previous layer values.
It is recommended to define layers at the project-level, config/blueprints
. This allow blueprints to be even more reusable.
More
More step-by-step docs are provided in the next documentation pages and go into more details on layering.