HomeDev GuideAPI Reference
Dev GuideAPI ReferenceUser GuideGitHubNuGetDev CommunityDoc feedbackLog In
GitHubNuGetDev CommunityDoc feedback


You need an **Optimizely cloud account** to access the self-services for Optimizely DXP. See [Creating an Optimizely Cloud Account](🔗) how to get an account.


Generic accounts like [_[email protected]_](🔗), or private hotmail-type accounts like [_[email protected]_](🔗), cannot be used. The self-deployment portal works best with browsers Chrome or Firefox.

## Verify site access before deployment

Before starting a deployment, make sure the site in the **source **environment is running by accessing it in a browser. If the site has _IP restrictions_ preventing you from navigating to it, ask the technical contact for the site to add your IP address in the exclusions list.

If you cannot reach the site, something is probably wrong and deployment cannot be done. Contact the technical contact for the site to solve the issue, and try again. When you have verified site availability, you can start the deployment.

## Deployment steps

This example deploys from the Integration to Preproduction environments, but the procedure is similar when deploying from Preproduction to Production.

Deployment issues

  1. Go to the DXP Service management portal on **<https://paasportal.episerver.net>** and log in with your account credentials. The **Organizations** section appears.


  2. Locate the organization and project for which you want to deploy changes, and click on the project name to open it.

  3. Click the **Hostnames** tab to see available hostnames.


  4. Click the **Deployments** tab of the **Project** page; it provides contact information and deployment options. 


  5. Before you start the deployment, verify that the source site works by viewing the application logs (**Troubleshoot-tab > Application Logs**). If the site works as expected, click **Deploy** to to start the deployment.

  6. Select the applicable options in the dialog box that appears:


    If you use **Zero downtime mode**, the **Use maintenance page** checkbox is automatically checked. A maintenance page is used only for sites that do not support Zero downtime mode or where it does not make sense such as for scheduler web apps and/or Commerce Manager.


    • **Zero downtime mode** – Select one of the following. See also [Smooth Deploy (Zero downtime deployments)](🔗).

    • **Not Applicable** – Select this option to not use Zero downtime mode.

    • **Read Only** – (Recommended) The cloned site runs in [ReadOnly-mode](🔗) so no new changes are applied to the temporarily cloned copy. No data loss occurs during the deployment.

    • **Read Write** – (Data loss likely) The cloned site runs in [ReadWrite-mode](🔗) and allows new data to be written to it.


    _Any data written to the cloned database while the deployment is running will be lost at the end of the deployment._ The ReadWrite mode increases compatibility with more features and add-ons, but should be used _only_ when data loss is acceptable for the site. (You should make editors aware that no updates should be made to the site during this phase of the deployment.)

    • **Use maintenance page** – If the deployment includes [database schema updates or changes to content types](🔗), select to display a maintenance page while the site is offline.

    • **Include Blobs & DB** – If it is a _first-time_ deployment to the target environment, select to copy these items over. Existing BLOBS and database are overwritten if you select the **Include Blobs & DB **option. If this option is _not_ selected, _only code_ will be copied.

    • **Select applications** –. If you have multiple web applications, you can select which ones to deploy.

  7. Click **Start Now**. A progress bar displays the progress of the deployment. When the first part of the deployment is done, a confirmation message appears in the portal. 

    • Click **View output log** to see deployment step details. See [Deployment process](🔗) for information about the procedure.

    • You can click **Cancel** to stop the deployment and roll back the changes, if needed.


  8. Click the **Preview...** link to verify that the sites in the slot is working as expected.


    An email is also sent to the technical contact for the target site, with links to the slot URLs that you can use for site verification.



    DO NOT continue with the deployment if you cannot properly verify a site in a slot.

    If there is a problem, you can fix the Integration environment and deploy it to Preproduction again, but the **Use maintenance page** or **Include Blobs & DB** options are not available. You cannot re-select the source applications as well; it auto-selects the source applications of the previous deployment.


  9. When you have successfully verified the sites in the previous step, click **Complete** to finalize the deployment. A progress bar appears, and the site in the slot is swapped into the Preproduction environment.


    Alternatively, if the deployment _did not succeed_, click **Reset** to revert the changes. The Preproduction environment is reverted to its initial state if a site did not work as expected in the first deployment part. Click **Reset** in the confirmation dialog box, to complete the reset, and go to the troubleshooting section below to solve the issues.



    If you selected **Use maintenance page**, you can roll back the database and validate the **Reset** progress.


  10. If you selected **Validate before swap**, click **Preview** to verify that the sites are working as expected after resetting, then click **Complete reset** to finalize the reset progress. 

  1. When completed, the project page displays the **Deploy** option again. You can click the information icon next to the environment name to see when the latest deployment was completed.

  1. If the deployment succeeded, verify that the Preproduction environment works as expected.

## Troubleshoot deployments

Notifications may appear at the top of the screen sent by the system administrator. Also, support information is provided if you have issues during deployment.

If an unsuccessful deployment occurs, an error message appears in the Project page.

Click **error log for detailed information** to see a summary of the deployment issues.

If the information is not sufficient to identify the issues, click **View Job Log** to open the **Job output** view. This contains detailed deployment information as described in the following section.

### Deployment job log output

This view provides information about the sites and environments involved in the deployment. You can also find exceptions, error messages, warnings and deployment output steps, useful when troubleshooting deployment issues.

Click **Get Detailed Log **to receive the same information in an email. This is useful if you want to share the information with someone without access to the portal.

### Log Stream

The _Log Stream_ options lets you view output from Optimizely log files to help in troubleshooting deployment errors. This option requires diagnostics logging to a BLOB storage being enabled, as described in the article [Enable diagnostics logging for Web Apps in Azure App Service](🔗).

Click **Open Log Stream Window** to access the log stream. You can hook on the Optimizely logs to monitor the live log stream from all sites instances. Click **Pause** or **Resume** to stop or continue the streaming of log information. Click **Clear **to remove the recent log output.

**Related blog post:** [Setting up Continuous Integration with Azure DevOps and Episerver DXC Service (Optimizely DXP) by Stephan Lonntorp](🔗)