Environment Management

1. General environment setup

In most cases, at least three environments must be set up per customer in advance to ensure a proper delivery process: Dev, Test, and Prod.

In this setup, all projects of the customer are developed within the same set of environments and the applications will/might share data accross themselves.

However, in some cases, it might be risky to have data shared across various applications of the client. Scenarios can be such as:

  • The application contains highly confidential data
  • Special, complex security hierarchy is required
  • Existing environments do not support features required

In these cases, it is recommended to set up the environments based on projects, instead of having the apps sharing the same environments for the client.

Such setup could look like as follows:

  • OSB DEV
  • OSB TEST
  • OSB PROD
  • OSB - Contract Mgmt DEV
  • OSB - Contract Mgmt TEST
  • OSB - Contract Mgmt PROD

The decision should be made carefully in advance, considering all possible future scenarios, as migrating the data afterwards can be a big challenge.

2. Environment Types

2.1. Development

  • Why: This environment will be used for customization purposes. All customizations must be done in this environment.

  • Where: A development environment can be set up in either the customer's tenant or inside the OSB tenant.

  • Suffix: DEV

2.2. Test

  • Why: In all cases, any change made in the development environment must be deployed to the test environment first. The environment will act as an internal and external (UAT) test environment.

    In more advanced cases, a separate internal test and UAT environment might be required.

    No customizations should be done on this environment in any cases!

  • Where: While an internal test environment can be set up in the OSB tenant, the UAT environment should always be set up in the customer's tenant.

  • Suffix: TEST/UAT

2.3. Production

  • Why: The production environment will contain the latest, tested version of the solution developed.

    No customizations should be done on this environment in any cases!

  • Where: While an internal test environment can be set up in the OSB tenant, the UAT environment should always be set up in the customer's tenant.

  • Suffix: PROD

3. Creating an environment

All Power Platform environments are subject to capacity constraints, meaning that the tenant must have enough available database storage left to create the new environment.

The remaining capacity can be checked in the Power Platform admin center.

To create a new environment:

  • Open the Power Platform admin center.
  • Choose the New option.
  • Fill in the details for the new environment:
    • Name: Provide a name, following our naming conventions guideline.
    • Region: A region, closest to the client should be provided (Europe / Switzerland in most cases)
    • Type:
      • Dev/Test: Sandbox
      • Prod: Production
    • Create a database for this environment: Yes
  • Choose the Next option and fill in further details:
    • Language: English
      Important! Always pick English as primary language. Other languages can be installed later.
    • URL: Always enter a custom URL by clicking on the link marked as here and providing a URL.
    • Currency: Define based on project requirements. The default currency cannot be changed later!
    • Enable Dynamics 365 Apps: Yes in most cases. If this option is set to No, installing Dynamics 365 apps will not be possible and the decision cannot be changed later! However, setting it to yes will increase the size of the environment.
  • Choose the Save option to create the new environment.

4. Application Users

Each environment should have at least one Application User set up. This application user can be used in Azure DevOps pipelines and other integration scenarios.

Please refer to the CI / CD guidelines for further details on the topic.