You can deploy solutions from your development environment to any cloud environment, as [code packages](🔗). You can also move database and BLOBs between environments using the [source environment API](🔗).
See also [DXL Cloud API](🔗) for Deployment REST APIs,
Caution
After going live, you can no longer overwrite the production database using the deployment API.
Optimizely takes care of the the following as part of the service:
Setup of environments.
Initial troubleshooting and roll-back if issues arise.
## Deployment to production
The following image illustrates deployment from a local development environment to _Production_. In this scenario the production environment is "empty" at 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, you can deploy to _Production_.
## Continuous deployment
After the first deployment, website users edit content in the _Production_ environment. As part of the upgrade process, you can move content from _Production_back to the \_Preproduction_ and \_Integration_environments, where developers can add new solution updates. See [Deploy code changes](🔗).
## Deployment methods
You can deploy either using deployment tools for a version-controlled team development environment, or through Visual Studio using the Optimizely extensions and publish profiles. In both cases you need to contact Optimizely 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.
## Important notifications
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.
To avoid data loss or corruption, if you have breaking changes where the old version of the sites' code cannot work with the new version of the database, deploy using _maintenance page_ when you deploy **database schema updates** or **changes to content types** . The target site is then taken offline showing the ([customizable](🔗)) maintenance page. If a deployment contains these type of changes, inform Optimizely when ordering deployment to production. You should also ensure that either the major or minor version is incremented to trigger the initialization module to make the necessary updates.
Note
If your changes are additive and do not break the sites when the old and the new code runs in parallel during deployment, you can deploy without using _maintenance page_.
When you deploy to a production environment, ensure that you apply the correct configurations. **Never** use credentials, tokens, or endpoints from a _Preproduction_ environment, in _Production_. You can set up environment-specific configurations that automatically apply depending on the environment; see [Environment configurations](🔗).
If you use **add-ons** on the site, ensure that you include the _modules_ and _modulesbin_ folders in the project so that these are published. Publish the _database schema_ on the first publish operation _only_.
You must install **add-on modules** to the \_Integration \_environment via NuGet to work with the DXC Service deployment process. The default configuration prevents users from installing add-ons on a production website; do not change this.
Before you deploy, add a wildcard binding to the site in the **Manage Websites**screen. This helps to prevent failures due to URL-dependent code when migrating the database between environments. See the following image, which shows an example of this binding.
Select **Admin > Configuration > Manage Sites**.
Click **Add** and add a wildcard (\*) Host Name.
## Related topics
[Create a new Optimizely Content Management System (CMS) site and deploying](🔗)
[Deploy an existing CMS site](🔗)
[Deploy an existing Optimizely Customized Commerce site](🔗)
[Deploy code changes](🔗)
Blog post: [Setting up Continuous Integration with Azure DevOps and Episerver DXC Service (Optimizely DXP)](🔗)