## Environment-specific configurations
When you deploy to a production environment, ensure that the correct configurations are applied. In a Production environment, you should **never** use credentials, tokens, or endpoints from a Preproduction environment.
Environment-specific configurations are also useful if you have an e-commerce site with payment provider methods that you do not want to run in a test environment, or if you want to apply specific log rules for an environment.
### Adding the configuration
Add the environment-specific configuration in _web.config_ for your web application. Alternatively, you can store the settings in the database and retrieve the settings based on environment name by adding the specific configurations for the environments (integration, preproduction, production) where you want them to apply.
Note
See the Azure portal to identify the environment names, see [Accessing Azure Information](🔗) to get access.
### Identifying the environment
To apply a specific configuration, you need to identify the environment name at runtime using **episerver:EnvironmentName**. You can retrieve the defined name for each environment setting from **Application settings** in Azure Portal.
Add the configuration for each environment requiring a specific configuration.
### Using the configuration
To apply a specific configuration and identify the environment at runtime, use the following code:
Applying this where needed picks the correct configuration for the running environment.
#### Defining site context
The following example defines and uses specific payment gateways and shipping methods for environments in an Optimizely Customized Commerce solution based on Optimizely Digital Experience Platform (DXP).
Create a class to act as a **global context** for the site.
#### Defining environment-specific payment gateways and shipping methods
Currently, the best way to separate payment gateways and shipping methods is to use a specific **prefix** for their system names. For example, you can set **Integration-** for the payment gateways and shipping methods used in Integration, **Preproduction-** for Preproduction and so on. The prefix should be in line with the enum defined in previous steps, for easier matching.
#### Getting payment gateways and shipping methods
Note
The code that displays the shipping method name to the user in the production environment might need modification to remove the prefix part.
## Events and BLOB providers
You need to change some configurations for the website to work with Azure. The **container** attribute for the BLOB provider and **topic** for the event provider should be unique per site, within the same storage or service bus account. Therefore you need to update the mapping for BLOBs and event providers.
Important
Do **not** skip this step! If you do, assets are stored locally, and will not deploy properly to the Azure BLOB storage.
Note
Adding Custom Application Settings and/or Custom Connection Strings is supported only through client code. Optimizely DXP does not support custom settings within the Azure Portal.
In Visual Studio, open _web.config_ and add the following configuration under the **episerver.framework** section.
**Do not change** the values for **connectionStringName**, because these are overwritten with the correct environment-specific values during deployment. Optionally, you can change the **container** and **topic** names **mysitemedia** and **MySiteEvents** to names of your choice. The storage container name must be in lowercase, for example _mysitemedia_, for DNS compatibility.
Compile the solution (**Build > Build Solution**) and run it.
Note
Your local site displays an error message because the site is pointing to Azure after the configuration changes. This is corrected when you publish the project to Azure.
Note
When you deploy a website, you may want settings in the _deployed application's_ _web.config_ to be different from your _local_ development _web.config_. Instead of changing these settings for your local installation (as done here), you can [apply a transformation of the web.config file](🔗) when you deploy to Azure to avoid breaking your local site.
## Configuration transforms
DXP supports the use of configuration transforms to make changes to .config-files when deploying between environments. Even though the following example is for a _web.config_ file, DXP supports this feature on **any \*.config file** if the transform file follows the naming convention (_OriginalFileName.**{EnvironmentName}.**config_).
If you deploy using **Deployment API**, you can deploy the code package to the **Integration** environment directly instead of the conventional way of publishing the code from Visual Studio. However, when you do so, configuration transformation is applied on the code being deployed to Integration (if the deployment engine sees a valid transformation file to apply). For example, if there is a _web.integration.config_, it is processed as part of the deployment flow. This is similar to when you deploy code from Integration to another environment using the DXP management portal. Deploying to Integration using Visual Studio **does not apply** any configuration transformation.
### Adding transform files
Add a file called_web.**{EnvironmentName}**.config_ (see [Identifying the environment](🔗) for naming conventions) at the **same level/folder** as the _web.config_ file you want to transform. If you have _web.config_ files at multiple levels/folders that needs transformation, add a transform file next to each one.
The _{EnvironmentName}_\-part should correspond to the **value** of the application setting with the same name of the target environment for the deployment. For example, to apply a transformation file to _web.config_ when deploying to the Preproduction environment, you add a file called _web.preproduction.config_ that contains the transformation you need.
If you need to do configuration transformations in _multiple_ environments (such as for both Preproduction and Production), then use _multiple transformation files_, which are applied either from the code package or one after the other as the deployment moves towards the production environment.
Note
The transform files always transform _web.config_ file in the same way but there is still a difference in behavior depending on if deployment is done between environments, or if deploying using a code package. When deploying between environments, the transformation will be applied to the _web.config_ from the **source** environment. When deploying from a code package, the transformation will be applied to the _web.config_ in the **code package**.
To make configuration transforms work from Visual Studio you need to make sure you add the transformation files as _content files_ so they are deployed together with the rest of the site.
### Configuration transformation syntax
When inserting elements into the configuration, the element can be removed before inserting it so that it depends less on the structure of the base configuration. This has the added benefit of the transform behaving the same in both code package and environment to environment deployments.
**Example:**
When transforming element attributes for appSettings for example, inserting the element first and then setting its attribute will ensure that it behaves the same regardless if the appSetting exists or not in the base configuration. This should also make the attribute-transformations easier to work with because they always behave the same.
**Example:**
For documentation regarding the transforms, see [Web.config Transformation Syntax (Microsoft)](🔗).
### Code package configuration transform
The base configuration file is taken from the code package and transformations are applied to all environments.
**Example:**
Code package is uploaded to Optimizely storage. It contains _web.config_, _web.Integration.config_, _web.preproduction.config_ and _web.production.config_.
The application is deployed to the **Integration** environment. Use _web.config_ as a base for transformations which a _web.Integration.config_ are applied to and a new _web.config_ is added to the **Integration** environment.
The application is deployed to **Preproduction** and the _web.preproduction.config_ transformation file is applied to _web.config_ from the code package, creating a new _web.config_ in **Preproduction** environment.
The application gets deployed to **Production**, and the _web.production.config_ file gets applied to _web.config_ from the code package, creating a new _web.config_ in **Production** environment.
### Environment to environment configuration transform
The base configuration file is taken from the source environment to apply transforms to, transformations are applied to **Preproduction** and **Production**.
**Example:**
The application is deployed to the **Integration** environment. It contains a _Web.config_ for that environment (no transformation is done in **Integration**), _web.preproduction.config_, and _web.production.config_.
The application is deployed to **Preproduction** and the _web.preproduction.config_ transformation file is applied to the _web.config_ used in Integration, creating a new _web.config_ in **Preproduction**.
The application gets deployed to **Production**, and the _web.production.config_ file gets applied to the _web.config_ from **Preproduction** environment.
The Production _web.config_ is therefore the result of both _web.preproduction.config_ and _web.production.config_ being applied to the original _web.config_ file that was used in the Integration environment. The transformation files need to follow the syntax described in [Web.config Transformation Syntax (Microsoft)](🔗).
### Adding transform files for Commerce Manager link
When deploying **Commerce Manager** between different environments, the link remains the same across these. Therefore, in some cases it will be pointing to the wrong one. As previously explained, you can use transform files, which takes care of updating Commerce Manager links specifically for each environment.
For example, for deploying to Preproduction a transform file could look like this:
## Custom maintenance page
During deployments where the site needs to be taken offline, you have the option to add a _custom maintenance page_ that will be displayed during the deploy. See [Custom Maintenance Page](🔗) for how to work with maintenance pages.
## Related topics
[Azure websites – block web access to non-production deployment slots](🔗)
[URL Rewrite Module Configuration Reference – Functionality Overview](🔗)
[How to transform web.config when deploying a web application project](🔗) (Microsoft)
Blog post: [Support for ApplicationHost transforms](🔗) in DXP by [David Buö](🔗)