Applies to versions: 7.5-11

ARCHIVED This content is retired and no longer maintained. See the latest version here.

Deploying

This topic explains deployment procedures in Optimizely Digital Experience Platform (DXP), that is publishing of code, database and content between the different environments.

In this topic

How it works
Deployment to production
Continuous deployment
Deployment methods
Important notifications

How it works

You can deploy solutions from your development environment to the Integration environment, as daily builds or continuous releases. When you are ready to go live, you can deploy to Preproduction and Production through the DXP Management Portal. This involves creating a backup of the existing environment, and moving the code to Preproduction, where you can verify that everything works.

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

Setup of environments.
Initial troubleshooting and roll-back if issues arise.
Deployment of production content back to Preproduction and Integration.

Deployment to production

The following image illustrates deployment from a local development environment to Production. In this scenario the production environment is "empty" at the beginning. 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.

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 new solution updates. See Deploying code changes.

Deployment methods

You can deploy either using deployment tools for a version-controlled team development environment, or through Visual Studio using the Optimizely extensions and publish profiles. In both cases you need to contact Optimizely before you deploy for the first time, to get the needed deployment integration settings information.

You can use any deployment tool that supports Azure Resource Manager (ARM), for example Octopus Deploy, Visual Studio Team Foundation Server or TeamCity. See Deploying code changes.

Important notifications

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 version of the database, deploy using maintenance page when you deploy database schema updates or changes to content types . (You can use the Compare database versions tool to compare database versions.) The target site is then taken offline showing the (customizable) maintenance page. If a deployment contains these type of changes, inform Optimizely when ordering deployment to production. You should also ensure that either 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, ensure that you 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. Publishing the database schema should only be performed on the first publish operation.
You must install add-on modules to the Integration environment via NuGet to work with the DXC Service deployment process. The default configuration prevents users from installing add-ons on a production website; do not change this.
Before you deploy, add a wildcard binding to the site in the Manage Websites screen. 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 > Config > Manage Websites.
2. Click Add and add a wildcard (*) Host Name.