In this topic
- How it works
- First-time deployment to production
- Continuous deployment
- Deployment methods
- Important notifications
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 through the Episerver self-deployment portal. This involves creating a backup of the existing environment, and moving the code to Preproduction, where you can verify that everything works.
Episerver takes care of the the following as part of the service:
- Setup of environments.
- Continuous deployment of code to Production after go-live.
- Initial troubleshooting and roll-back if issues arise.
- Deployment of production content back to Preproduction and Integration.
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. 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 to go live, you contact Episerver to deploy to Production.
The image below illustrates the scenario after a first-time deployment of code and content to production. After the first deployment, website users edit content in the Production environment. As part of the upgrade process, content can be moved by Episerver from Production back to the Preproduction and Integration environments, where new solution updates are added by developers. See Deploying code changes.
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 Deploy, Visual Studio Team Foundation Server or TeamCity. See Deploying code changes for more information.
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.
- 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.
- When deploying to a production environment, always ensure that the correct configurations are applied. You should never use credentials, tokens or endpoints from a Preproduction environment, in Production. You can set up environment-specific configurations that will automatically apply depending on the environment, see Environment configurations.
- 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. 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.
The following topics describe scenarios for first-time deployment to Integration: