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

Deploy DXP

Explains deployment procedures in Optimizely Digital Experience Platform (DXP), such as publishing of code, database and content between the different environments.

Suggest Edits

📘

Note

Deploying to Windows app services for clients using Optimizely Content Management System (CMS) 12 is not currently supported.

You can deploy solutions from your development environment to any cloud environment as code packages. You can also move databases and BLOBs between environments using the source environment API.

See also DXP Cloud API for Deployment REST APIs.

🚧

Caution

After going live, you can no longer overwrite the production database using the deployment API.

Optimizely takes care of the following as part of the service:

  • Setup of environments.
  • Initial troubleshooting and roll-back if issues arise.

Deploy to production

The following image illustrates deployment from a local development environment to Production. In this scenario, the production environment is "empty" initially. You first create code and content in your local development environment and then push this to your Integration environment. You then deploy to Preproduction and validate that everything works as expected. When ready, you can deploy to Production.

deployment from a local development environment to Production

Continuous deployment 

After the first deployment, website users edit content in the Production environment. As part of the upgrade process, you can move content from Production back to the Preproduction and  Integration environments, where developers can add solution updates. See Deploy code changes.

Recommended deployments

📘

Note

Read through and follow the recommendations below to make deployment as smooth as possible.

  • Make sure that the software you deploy supports Azure Web Apps. See Requirements for supported software and components.

  • To avoid data loss or corruption, if you have breaking changes where the old version of the sites' code cannot work with the new database version, deploy using maintenance page when you deploy database schema updates or changes to content types. The target site is then taken offline, showing the (customizable) maintenance page. If a deployment contains these types of changes, inform Optimizely when ordering deployment to production. You should also ensure that the major or minor version is incremented to trigger the initialization module to make the necessary updates.

    📘

    Note

    If your changes are additive and do not break the sites when the old and the new code runs in parallel during deployment, you can deploy without using maintenance page.

  • When you deploy to a production environment, apply the correct configurations.  Never use credentials, tokens, or endpoints from a Preproduction environment, in Production. You can set up environment-specific configurations that automatically apply depending on the environment; see Environment configurations.

  • If you use add-ons on the site, ensure that you include the modules and modulesbin folders in the project so that these are published. Publish the database schema on the first publish operation only.

  • Before you deploy, add a wildcard binding to the site in the Manage Websitesscreen. This helps to prevent failures due to URL-dependent code when migrating the database between environments. See the following image, which shows an example of this binding.

    1. Select Admin > Configuration > Manage Sites.
    2. Click Add and add a wildcard (*) Host Name.

    Click Add and add a wildcard Host

Related topics

Updated 5 months ago