Understanding Environments
Environments serve as isolated workspaces where you can experiment, test, and make changes to your models, content, and code without changing your live production environment until you're ready.
With an Enterprise plan, you can set up up to three (in total) environments tailored to your specific needs, such as Dev, QA, and Prod. Each environment represents a distinct stage in the production cycle, where you can seamlessly transition your work from one environment to another.
Use cases
Uses cases for environments can include:
- Code updates independent of Builder: Adding a "Summer's here!" heading to a beta page, tests for Builder-related issues, then pushes changes to main environment.
- Model schema change: In a Image data model, you remove the descriptor text that appears below the image in the dev environment. After testing for any issues on the dev website, you can push the changes to the main environment, reflecting them on the live website.
Sync automatically
Live Sync, which is on by default, automatically provides:
- Real-time synchronization of models and content across linked environments.
- Synchronization of changes made in the parent environment to the child environments.
Push changes when you're ready
When your deliverable is ready for publication, you manually push the updates.
This gives you:
- Control of the update process.
- Control over the timing and propagation of changes.
- A way to carefully review before deploying updates to the production environment.
Re-sync to mirror the parent space
When the parent space, such as main (also known as the production environment), has changes that you'd like to pull down to the child spaces, you can re-sync to update the child environment. Re-syncing:
- Resets and synchronizes an environment with the parent space.
- Deletes existing models and content in the environment.
- Replaces models and content with the latest versions from the parent space.
- Ensures consistency and maintains an up-to-date development environment.