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.
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.
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.
While the automation of Live Sync is convenient, you can also turn off this feature as needed for specific models and content entries. This means you can make modifications and testing without impacting the main environment.
For more detail, see Syncing environments with Live Sync section of Using Environments.
With multiple environments, you can work in a non-production environment to refine your project without risking works-in-progress showing up on your live site. 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.
For more detail, see Pushing changes from a child environment section of Using Environments.
When you create an environment, it mirrors the parent (production) environment by default. As you make changes to that child environment though—through actions such as content, model, or user changes—you have to push the changes in the child environment to the parent environment. Alternatively, if you would like to discard those changes, you can reset the child environment by re-syncing the child with the parent.
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.
For more detail, see the Re-syncing an environment section of Using Environments.
With bulk linking, unlinking, and pushing capabilities, teams can streamline content synchronization and deployment processes. Here's a summary of the bulk actions available in Builder's environments:
- Bulk linking: Simultaneously link multiple unlinked content entries to ensure synchronization between environments.
- Bulk unlinking: Unlink multiple content entries to discontinue live updates for those entries.
- Bulk pushing: Push multiple content entries to a chosen destination environment to overwrite any existing content in that environment.
For more information, read Bulk Actions in Environments.
Environment-based permissions in Builder provide fine-grained control over user access and actions so you can streamline collaboration and development processes.
You can customize roles specific to environments, granting or restricting permissions such as linking content, pushing content and models, or requesting pushes.
Users with restricted access can request pushes to move their completed work to the next environment, and Admins can review and respond to these requests.
For more information, read Managing Environment Permissions.
You can integrate your code with a non-main environment so you can develop and test before deployment. In this way, you can make sure updates are as intended upon delivery.
For instructions on integrating an environment with your code base, read Integrating an Environment with Your Code.
When you are setting up your process for development and content creation with Builder, it's helpful to understand the options available. Both Environments and Workflows are designed to enhance the content creation and development processes for teams.
Environments offer separate workspaces for different versions and instances of content and models, allowing teams to work in isolated environments, test changes, and seamlessly synchronize updates.
However, Workflows provide a structured approach to content governance by defining stages, roles, and responsibilities, which helps streamline production, ensure content quality, and foster better collaboration.
The table below shows a comparison of Workflows and Environments in Builder:
| Environments | Workflows | |
|---|---|---|
Purpose | Separate workspaces for working on different versions of your content and models. Typically used for development, testing, or staging purposes. | Define and manage the content creation process within the platform. Create a structured process with stages, roles, and responsibilities for creating, reviewing, and publishing content. |
Functionality | Sync or unlink models and content between different environments. Live Sync is on by default, for real-time synchronization of changes between environments. However, you can turn off Live Sync to work on specific models or content independently. | Define stages—for example, Draft, In Progress, Ready for Review, Completed—and assign roles or individual users to each stage. Incorporate Rules, which are specific criteria for content approval and movement through stages. |
Benefits | Flexibility and control over managing different versions or stages of content and models. Make changes in isolated environments before pushing them to the main environment, ensuring a controlled and organized development process. | Ensure consistent and structured content creation, improve content quality, streamline production, and enhance collaboration among team members. |
Setup | Create child environments, turn Live Sync on or off for models and content in each environment, and manually push changes from child environments to the main environment or other child environments. | Define the Workflow name, description, owners, models to apply the Workflow to, and stages with associated roles and Rules. |
By leveraging Workflows and Environments, teams can optimize their deliverable processes, ensuring efficient content creation, development, and deployment while maintaining control and flexibility throughout the workflow.
If you're ready to get started with Environments, read Setting Up Environments.
