Disclaimer: This website requires Please enable JavaScript in your browser settings for the best experience.

HomeDev GuideAPI Reference
Dev GuideAPI ReferenceLegal TermsDev CommunityOptimizely AcademySubmit a ticketLog In
Dev Guide

Smooth deploy

Shows how to make a smooth deployment with the Optimizely Digital Experience Platform (DXP).

📘

Note

Smooth deployment is available for Optimizely Content Management System (CMS) only.

Smooth deployment, or Zero Downtime Deployments (ZDD), applies database changes without taking the site offline or using a maintenance page.

Deployment logic

The deployment engine creates a cloned environment that includes a copy of the Web App code and the database. This cloned environment manages external traffic for the duration of deployment so that you can update the original database as needed without affecting the external-facing websites.

You can run the external website in the following modes:

  • ReadOnly mode (recommended) – The cloned site will need to run in ReadOnly-mode because database writes are disabled during the deployment. This ensures that no changes are applied to the temporary cloned copy of the environment. No data loss will occur when the cloned copy is removed after the deployment finishes.

    🚧

    Important

    You need to implement support for ReadOnly-mode for this to work.

  • ReadWrite mode (data loss likely) – The cloned site runs in ReadWrite-mode and allows new data to be written to it.

    ❗️

    Warning

    Any data written to the cloned database while the deployment is running will be lost at the end of the deployment. The ReadWrite mode increases compatibility with more features and add-ons, but should be used only when data loss is acceptable for the site. (You should make editors aware that no updates should be made to the site during this phase of the deployment.)

    This diagram visualizes how the setup works during a deployment:

Failed deployment recovery options

You have the following recovery options if changes do not go as planned:

  • Roll-forward – If you can correct the problem by another code deployment, you can do this while the cloned environment still manages traffic to avoid the time it takes to set up another clone. When the new code version is deployed, you can validate the results before the deployment is completed.
  • Roll back code and database – You can automatically roll back the database to a safe time (before changes were applied from the new deployment). This mode also returns to the previous Web App code version. You can validate the code and database before the previous version is enabled to receive traffic.
  • Roll back code only – If only the code needs to be rolled back, you can keep the database as-is. You can validate the code and database before the previous version is enabled to receive traffic.