Builder Environments

Builder has support for multiple environments within a space. The default environment of a space is called Main and additional environments are referred to as "child environments". Additional information about environments can be found in Builder's official documentation.

Environment hierarchy

In a typical setup, Main represents production, while child environments could represent development, QA, staging, etc. Child environments are considered siblings in the sense Builder itself doesn't make a distinction between them - that "staging" would be a parent environment of "development", for example.

Sync between environments

By default, live sync is enabled in all environments; meaning that models and content created in Main, get automatically created and updated in all child environments. During development, model and content creation can be done safely in a child environment without impacting the production website. In order to make changes in existing models or content, one must first unlink them, make the necessary changes, and push them once they are ready for production. This process can be done in stages (Development → Test → Staging → Production) in case multiple environments are available.

Caveats

It will be often the case that some of the content in an environment will refer to entities that exist outside Builder itself - for example: a piece of content points to a product category in PIM, or a page component to an image in DAM, or even data present in other external systems. Once that content is pushed to a different environment, it will carry their original reference to the respective entity in PIM, DAM, etc. used in the original environment, which might not be the same used in the destination one. In such cases, unless mechanisms are put in place to ensure that the date is the same in both places, the content will need to be adjusted manually in the destination.

In order to minimize manual intervention, we recommend the following practices:

Bizzkit DAM File plugin

The data produced by the plugin contains a properly called filePath, that can be used in combination with the GET /api/{culture}/files/by-path endpoint in DAM to lookup the fileId associated with that path. This is a reliable fallback behavior, as long as the files are named the same, and are placed within in a folder structure with the same name.