Loading...
Area: Episerver DXC Service
Applies to versions: Not applicable

Deployment process

In Episerver DXC Service, you can manage deployments using the DXC Service Management Portal. This topic explains the high-level steps performed when pushing code changes between environments. 

Deployment steps

When deploying, Episerver's deployment automation engine performs the following steps.

1. Packaging of code from source environment

This step creates a deployment package of the code in the source environment. Note the following:

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

2. A new slot is created on the target environment

This slot always has the same configuration as the current production slot. Other settings, such as logging to BLOB storage, are also 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 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 is applied on the target. See Environment configurations.

6. Warmup is configured for the target slot

The deployment engine checks for an applicationInitialization section in web.config; if none exists, it is created. See Warming up sites.

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

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

The slot scales to the same level as the current production site so it can 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 site is configured to respond to the slot address. See Before going live step 1 in the Going live.

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.

Related topics

Last updated: Feb 04, 2019