Multi-Experience Operations enables concurrent, site-level code deployments for environments with multiple sites. This method minimizes downtime because each site enters maintenance mode only during its specific update instead of the entire environment-wide deployment.
Key Features
Concurrency: Simultaneous site updates reduce total deployment time.
Prioritization: User-defined sequences establish the site update order.
Deployment Control: Stop an active deployment. To continue, submit a new code deployment:
Same code version: The platform resumes from where the previous deployment stopped.
New code version: The platform deploys the new version to all sites, starting from the beginning.
Deployment configuration
To initialize a deployment, you must first configure your environment settings and then do the code switch.
Pre-deployment configuration
This configuration is optional because the platform updates three sites concurrently in a standard sequence by default. You must complete this configuration only if a specific workflow requires a custom deployment order or a different concurrency limit.
To set concurrency, navigate to Configuration and select Code Deploy.
Enter the number of simultaneous site updates in the Concurrent updates field. The default value is 3.
Click Save.
Set up the update order
To setup the update order:
On the environment overview page, navigate to the Sites list.
Click the three dots and select Edit update order to define the sequence for the sites.
Click Save.
Initiate a deployment
On the environment overview page, click Switch code.
Select the target branch or tag for the new code.
To run hooks during deployment, select the Run Cloud Hooks. This step is optional. If you do not select this option, the platform bypasses the hooks.
If you select the Run Cloud Hooks, enter Cloud Hook arguments to pass specific maintenance mode triggers or conditional logic.
Click Switch to begin the deployment.
Active deployment management
During an active deployment, the interface displays the status of individual sites. To manage the queue, click Stop to cancel the deployment process. Submit a new code deployment promptly to ensure that sites do not split between two code versions.
Important
After a Stop action, you must submit a new code deployment with the same code version or a new code version to bring all sites into a consistent state.
Technical requirements for Cloud Hooks
Site-level maintenance mode requires specific updates to Cloud Hook scripts. For additional information on Cloud Hooks, refer to Automating with Cloud Hooks.
Site-Level Triggers: Configure hooks to respond to the pre-site-code-update and post-site-code-update events. These are the only available site-level hook events.
Minimum Recommended Snippet Logic:
pre-site-code-update: Put the specific site into maintenance mode.
post-site-code-update: Run required database updates and take the site out of maintenance mode.
Process Arguments: This step is optional. If a workflow requires custom parameters or logic overrides, update hook scripts to process arguments that pass from Switch Code UI. Hooks that do not use arguments continue to function normally.
Test: Run the hook scripts manually through an SSH session to verify their behavior and debug logic before you rely on them in the deployment queue.
Switch code sequence
A Switch Code operation in an MEO environment proceeds in the following sequence:
Cron jobs run with the new code version during the early stages of the rollout.
A second rollout of pods launches with the new code.
Pre-environment Cloud Hooks run.
The platform moves sites to the new code in batches based on the concurrency configuration:
The pre-site-code-update hooks run for each site in the batch.
The platform switches the ingress to point site traffic to the new code for each specific site instance.
The post-site-code-update hooks run for each site in the batch.
The platform updates the code version for the site.
Post-environment Cloud Hooks run.
SSH access uses the previous code version until the final deployment steps complete.
Stop a code deployment
When you stop an active deployment, the following events occur:
A stop task request displays in the User Interface (UI).
The task log of the original code deployment task includes the task ID of the stop request.
The platform terminates active Cloud Hooks and Cloud Actions.
A stopped deployment leaves the environment in a split state because the ingress switches to the new code on a per-site basis as sites progress through the queue. You must submit a new code deployment promptly to ensure that sites do not remain split between two code versions.
Note
MEO code deployments take an average of 3 to 8 minutes because the platform runs two rollouts of pods. If site-level hooks are slow, increase the concurrency setting to reduce the total deployment duration.
Troubleshooting
Deployment failures
If a code deployment task fails, complete these steps:
Review the task logs to determine whether a platform issue or a Cloud Hook script error caused the failure.
For platform failures, retry the deployment. If the failure persists, open a Support ticket and include the task ID.
For Cloud Hook failures, debug the script code. Test the scripts manually through an SSH session.
Recover from a failure
To bring all sites back to a consistent state after a split-state failure or a stopped deployment:
Resolve all hook errors.
Test the scripts manually through an SSH session.
Submit a new full code deployment with the same code version or a new code version.
External service calls in cloud hooks
If Cloud Hooks call external services such as APIs, third-party integrations, and Content Delivery Network (CDN) purge endpoints, ensure that the scripts include the following:
Retry logic: Handle transient failures such as network timeouts and 5xx responses gracefully to prevent unnecessary deployment errors.
Timeouts: Set explicit connection and execution timeouts to prevent hooks from entering an unresponsive state and to ensure that they do not block the deployment queue. Each site-level or environment-level hook has a maximum execution time of 3 hours.
A hook that enters an unresponsive state on an external service blocks the batch slot of that site. This action reduces effective concurrency and extends the total deployment time.
Code version overview
The code version on the Sites page indicates whether Cloud Hooks are complete for that site and whether the site uses the new code. A site can serve the new code before the codeVersion field updates in the UI. The update sequence for each site runs as follows:
Pre-site hooks run.
The system directs site traffic to the new code.
Post-site hooks run.
The code version updates after all hooks complete. If a post-site hook fails, the site runs the new code and the UI displays the previous code version.
Site re-association in a deployment
If you disassociate a site from an environment and re-associate it within the grace period before deletion, the site instance restores to a Ready state. However, the code version does not update to the latest deployed commit.
After re-association, you must submit a full code deployment for the environment. This deployment skips the sites that already use the current version. This process is similar to a new site association and sets the code version to the current version.
Code Deployment Management
Multi-Experience Operations enables concurrent, site-level code deployments for environments with multiple sites. This method minimizes downtime because each site enters maintenance mode only during its specific update instead of the entire environment-wide deployment.
Key Features
Concurrency: Simultaneous site updates reduce total deployment time.
Prioritization: User-defined sequences establish the site update order.
Deployment Control: Stop an active deployment. To continue, submit a new code deployment:
Same code version: The platform resumes from where the previous deployment stopped.
New code version: The platform deploys the new version to all sites, starting from the beginning.
Deployment configuration
To initialize a deployment, you must first configure your environment settings and then do the code switch.
Pre-deployment configuration
This configuration is optional because the platform updates three sites concurrently in a standard sequence by default. You must complete this configuration only if a specific workflow requires a custom deployment order or a different concurrency limit.
To set concurrency, navigate to Configuration and select Code Deploy.
Enter the number of simultaneous site updates in the Concurrent updates field. The default value is 3.
Click Save.
Set up the update order
To setup the update order:
On the environment overview page, navigate to the Sites list.
Click the three dots and select Edit update order to define the sequence for the sites.
Click Save.
Initiate a deployment
On the environment overview page, click Switch code.
Select the target branch or tag for the new code.
To run hooks during deployment, select the Run Cloud Hooks. This step is optional. If you do not select this option, the platform bypasses the hooks.
If you select the Run Cloud Hooks, enter Cloud Hook arguments to pass specific maintenance mode triggers or conditional logic.
Click Switch to begin the deployment.
Active deployment management
During an active deployment, the interface displays the status of individual sites. To manage the queue, click Stop to cancel the deployment process. Submit a new code deployment promptly to ensure that sites do not split between two code versions.
Important
After a Stop action, you must submit a new code deployment with the same code version or a new code version to bring all sites into a consistent state.
Technical requirements for Cloud Hooks
Site-level maintenance mode requires specific updates to Cloud Hook scripts. For additional information on Cloud Hooks, refer to Automating with Cloud Hooks.
Site-Level Triggers: Configure hooks to respond to the pre-site-code-update and post-site-code-update events. These are the only available site-level hook events.
Minimum Recommended Snippet Logic:
pre-site-code-update: Put the specific site into maintenance mode.
post-site-code-update: Run required database updates and take the site out of maintenance mode.
Process Arguments: This step is optional. If a workflow requires custom parameters or logic overrides, update hook scripts to process arguments that pass from Switch Code UI. Hooks that do not use arguments continue to function normally.
Test: Run the hook scripts manually through an SSH session to verify their behavior and debug logic before you rely on them in the deployment queue.
Switch code sequence
A Switch Code operation in an MEO environment proceeds in the following sequence:
Cron jobs run with the new code version during the early stages of the rollout.
A second rollout of pods launches with the new code.
Pre-environment Cloud Hooks run.
The platform moves sites to the new code in batches based on the concurrency configuration:
The pre-site-code-update hooks run for each site in the batch.
The platform switches the ingress to point site traffic to the new code for each specific site instance.
The post-site-code-update hooks run for each site in the batch.
The platform updates the code version for the site.
Post-environment Cloud Hooks run.
SSH access uses the previous code version until the final deployment steps complete.
Stop a code deployment
When you stop an active deployment, the following events occur:
A stop task request displays in the User Interface (UI).
The task log of the original code deployment task includes the task ID of the stop request.
The platform terminates active Cloud Hooks and Cloud Actions.
A stopped deployment leaves the environment in a split state because the ingress switches to the new code on a per-site basis as sites progress through the queue. You must submit a new code deployment promptly to ensure that sites do not remain split between two code versions.
Note
MEO code deployments take an average of 3 to 8 minutes because the platform runs two rollouts of pods. If site-level hooks are slow, increase the concurrency setting to reduce the total deployment duration.
Troubleshooting
Deployment failures
If a code deployment task fails, complete these steps:
Review the task logs to determine whether a platform issue or a Cloud Hook script error caused the failure.
For platform failures, retry the deployment. If the failure persists, open a Support ticket and include the task ID.
For Cloud Hook failures, debug the script code. Test the scripts manually through an SSH session.
Recover from a failure
To bring all sites back to a consistent state after a split-state failure or a stopped deployment:
Resolve all hook errors.
Test the scripts manually through an SSH session.
Submit a new full code deployment with the same code version or a new code version.
External service calls in cloud hooks
If Cloud Hooks call external services such as APIs, third-party integrations, and Content Delivery Network (CDN) purge endpoints, ensure that the scripts include the following:
Retry logic: Handle transient failures such as network timeouts and 5xx responses gracefully to prevent unnecessary deployment errors.
Timeouts: Set explicit connection and execution timeouts to prevent hooks from entering an unresponsive state and to ensure that they do not block the deployment queue. Each site-level or environment-level hook has a maximum execution time of 3 hours.
A hook that enters an unresponsive state on an external service blocks the batch slot of that site. This action reduces effective concurrency and extends the total deployment time.
Code version overview
The code version on the Sites page indicates whether Cloud Hooks are complete for that site and whether the site uses the new code. A site can serve the new code before the codeVersion field updates in the UI. The update sequence for each site runs as follows:
Pre-site hooks run.
The system directs site traffic to the new code.
Post-site hooks run.
The code version updates after all hooks complete. If a post-site hook fails, the site runs the new code and the UI displays the previous code version.
Site re-association in a deployment
If you disassociate a site from an environment and re-associate it within the grace period before deletion, the site instance restores to a Ready state. However, the code version does not update to the latest deployed commit.
After re-association, you must submit a full code deployment for the environment. This deployment skips the sites that already use the current version. This process is similar to a new site association and sets the code version to the current version.
Did not find what you were looking for?
If this content did not answer your questions, try searching or contacting our support team for further assistance.
Did not find what you were looking for?
If this content did not answer your questions, try searching or contacting our support team for further assistance.
Multi-Experience Operations