Hide menu Last updated: Jun 20 2017
Area: Episerver DXC Service Applies to versions: Not applicable

Deploying

This topic explains the Episerver Digital Experience Cloud Service deployment procedure. Deployment means publishing of code, database and content between the different environments.

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 send a request to Episerver, who will create a backup of the existing environment, move the code to Preproduction, verify that everything works, and then deploy to Production.

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

  • Set up of environments.
  • First-time deployment of code, content and configuration to Preproduction and Production.
  • Initial troubleshooting and roll-back if issues arise.
  • Continuous deployment of code to Preproduction and Production after go-live.
  • Deployment of production content back to Preproduction and Integration.

Note: You need to contact Episerver to register a ticket to initiate deployment to Preproduction and Production environments, since this can only be done by Episerver.

First-time deployment to production

The image below illustrates a first-time deployment from a local development environment to production. In this scenario the Production environment is "empty" from the beginning. Code and content are first created in your local development environment, and then moved into the Integration environment. When ready for moving into Preproduction or Production, the deployment will be done by Episerver.

Continuous deployment 

The image below illustrates the scenario after a first-time deployment of code and content to production. After the first deployment, website users will edit content in the Production environment. As part of the upgrade process, content can be moved by Episerver from Production back to the Integration and Preproduction environments, where code updates can be applied directly by developers. 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 Episerver extensions and publish profiles. In both cases you need to contact Episerver 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 DeployVisual Studio Team Foundation Server or TeamCity. See Deploying code changes for more information.

Important notifications

Ensure that you 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. 
      
  • When deploying database schema updates (use the Compare database versions tool to compare database versions) or changes to content types, the target site will be put offline, and will display a maintenance page during deployment to avoid data loss or corruption. The maintenance page can be customized. If a deployment contains these type of changes, ensure to inform Episerver when ordering deployment to production. 
      
  • If add-ons are used on the site, ensure that the modules and modulesbin folders are included in the project so that these are published as well. Publishing the database schema should only be performed on the first publish operation.
       
  • Add-on modules must be installed to the Integration environment via NuGet to work with the DXC Service deployment process. The default configuration disables users to install add-ons on a production website and must not be changed.

Related topics

The following topics describe scenarios for first-time deployment to Integration:

Comments