Staging allows you to easily transfer changes made to pages or objects from one Xperience instance to another Xperience instance (typically hosted on a different server). You can also perform complete synchronization of all pages and objects. All connected instances must use the same version of Xperience. Staging is particularly useful if you need to synchronize multiple environments during development, for example:
Development -> Testing -> Editing (staging) -> Live (production)
All pages stored in the content tree of websites can be synchronized. However, not all objects in Xperience support synchronization. Make sure you read through the What can be synchronized section for more information.
Staging topology overview
Every "instance" within the staging topology consists of the following components:
- The Xperience administration application used to manage content and objects
- The MVC application that provides the live website
- One Xperience database shared by the applications
Configure staging between the Xperience administration applications, which then provide the transfer of data between the databases of the given instances. The MVC applications within individual staging instances then use the shared data to present the website.
Setting up staging
Configuring content staging – to allow synchronization, you need to configure the Xperience instances that you wish to connect.
Bi-directional content staging – explains how to configure servers to be both target and source servers at the same time. Allows transferring of changes in both directions.
Using X.509 authentication – learn how to secure the staging service using X.509 certificates.
Staging large files – Xperience supports staging of physical files stored as Page attachments and in Media libraries. Learn how to limit the maximum allowed size of synchronized files, and how to ensure synchronization of extremely large files between servers.
Content staging security – learn about the permissions that roles need to perform synchronization actions.
Synchronizing content – explains how to transfer synchronization tasks to other servers.
Automatic content synchronization – set up the system to perform synchronization automatically.
Exporting and importing sites – you can also manually transfer your content to other instances of Xperience using the export and import features.
Troubleshooting staging – check for solutions to problems that can occur when using staging.
What can be synchronized
Content staging supports synchronization of the following data:
- Page data – pages in the website content tree, their content, URLs, and more.
- Pages need to be on the same place in the content tree on both the source and target servers.
- Timeout defined for pages that are part of a workflow is not synchronized for consistency reasons.
- Page file attachments – if a page contains attachments or file fields, the files are synchronized together with the page.
- Page relationships – relationships between pages are synchronized if the relationship type and both pages exist on the target server.
- Page templates created for MVC pages – synchronization is supported only for custom page templates (which are created from a default page template).
- Workflow process – only published page versions are synchronized to the target server and both servers need to have the same workflow schema defined.
- Email feeds – when staging email feeds, we recommend setting the staging of child and binding objects to incremental to avoid overwriting individual email issues and their statistics.
- Email widgets
- Custom tables and their data.
- Media libraries and the files and folders in them.
- ACLs (page-level permissions)
- Global objects – all global objects with the exceptions listed below.
Content staging does not support synchronization of the following data:
- Contacts (the state of contacts in automation processes is also not synchronized)
- Custom modules
- Event log
- Export history
- Form data (the actual form objects are synchronized)
- Sites (the global objects holding the properties of sites in the system)
- Web farm servers
- Object data fields that store various types of live site data or statistics (e.g. the status and statistics of campaigns)
- Physical files associated with global objects (for example web part source file, form control files)
- Database views and stored procedures managed through the Database objects application
- Object code stored and edited in physical files via deployment mode or source control mode
- On source servers, staging tasks are generated only if you edit code in the Xperience administration interface or after you synchronize changes from files into the database.
- On target servers, staging tasks do not update object code if deployment or source control mode is enabled.
When you stage an object, the synchronization also includes all child objects and bindings (relationships with other objects) in most cases.
For example: A role is not assigned to any users in the development environment, but to 100 users on the target production server. If you synchronize the role object through staging, the users are removed from the role on the target server.
To avoid potential problems, we strongly recommend having mirrored content and consistent objects on all staging servers whenever possible. Developers can also customize the staging of child and binding objects to adjust the behavior according to your environment's requirements.
Staging and ID values
Content staging cannot ensure that objects and pages have the same ID values after being transferred to a different environment. However, the synchronization process preserves GUID values. Use GUID fields if you need to identify pages or objects across multiple staging environments.