Hide menu Last updated: Mar 08 2017
Area: Episerver DXC Service Applies to versions: Not applicable

Deployment process

With Episerver DXC Service you can deploy solutions from your development environment to the Integration environment, while Episerver manages the deployment into production when going live. This topic describes the high-level steps performed by Episerver's deployment automation engine, when pushing code changes to Preproduction and Production environments.

Deployment steps

When you are ready to push your changes from one environment to another, Integration to Preproduction, or Preproduction to Production, Episerver's deployment automation engine will perform the following steps:

1. Packaging of code from source environment

In this step a deployment package of the code is created in the source environment.

Notice the following:

  • No files with the .log-extension will be included.
  • If a file with extension .txt cannot be read, for example if it is locked by another process, it will be skipped.
  • Any locked files under wwwroot\App_Data\ will be ignored.
  • Everything under wwwroot\App_Data\Blobs will be excluded (should not be used in Azure).

2. A new slot is created on the target environment

This slot will always have the same configuration as the current production slot. Other settings, such as logging to Blob storage, will also be configured according to DXC Service standards. At this stage, the slot is in a stopped state.

3. Code is deployed to the new slot

The code package created in step one is now deployed to the new slot.

4. Monitoring and extensions are prepared

Extensions like New Relic for application performance monitoring, are installed on the slot and configured according to DXC Service standards.

5. Configuration transforms are applied

Any configuration transforms included in the code package matching the target environment will now be applied on the target. See Environment configurations.

6. Warmup is configured for the target slot

The deployment engine checks if an applicationInitialization section exists in web.config, if not it will automatically be created. See Warming up sites.

7. The slot is started and gets prepared for "Go Live"

At this stage, the slot gets started and a "swap with preview" is initiated. The deployment engine monitors the site until it has completely started and warm up has finished for all its instances.

The slot will scale to the same level as the current production site to make it possible for it to handle the production traffic load after the swap.

8. Manual validation of the site

A manual "smoke test" is performed to verify that the site works as expected. For this to work it is important that your Episerver CMS is configured to respond to the slot address. See Before going live step 1 in the Going live topic.

9. Go Live/Reset

If the site works as expected, it is now swapped into the site's "production slot" of the current target environment (Preproduction or Production) and the old slot is stopped. If the site in the slot does not behave as expected, the swap is aborted and the slot site stopped. The files are saved for troubleshooting purposes, or until a new deployment is attempted.