Customer engagement apps environments
Microsoft Power Platform environments provide a space to store, manage, and share business data, apps, chatbots, and flows. It also serves as a container to separate apps that might have different roles, security requirements, or target audiences. How you choose to use environments depends on your organization and the apps that you’re trying to build. Dynamics 365 apps also use Microsoft Power Platform environments.
To follow healthy application lifecycle management (ALM) principles, you’ll need separate environments for app development and production. Though you can perform basic ALM with only separate development and production environments, we recommend that you also maintain at least one test environment that’s separate from your development and production environments. When you have a separate test environment, you can perform end-to-end validation that includes solution deployment and application testing. Some organizations might also need more environments for user acceptance testing (UAT), systems integration testing (SIT), and training.
Some project teams also use separate development environments, which can be helpful in isolating changes from one work effort being checked in before it’s completed. Separate development environments can also be helpful in reducing situations when one person negatively affects another while making changes.
Purpose of environments
The purpose and number of environments that you need are dependent on your ALM and the needs of your project. Three common purposes for creating environments that every project should have:
- Development
- Test
- Production
These three purposes are also referred to as dev-test-prod. Production is the live system where users do their work with the solutions that you’ve built for them.
Development environment
In the development environment, you should do all the development, configuration, and customization to the system. This environment should only have fake data to perform simple tests of the system. The end users will rarely have access to the development environment. Developers and customizers are the ones who can make changes to the system and will need access to this environment. Every change, piece of code, and configuration should always be done in the development environment first.
Make sure that you don’t perform experiments or prototypes in your main development environment. For example, consider a situation where you plan to test a new product for integration and then install it in development to try it out. While the product was installed, your other customizations picked up dependencies on it. This incident could break your ALM process or introduce dependencies into test and production that you don’t want. To avoid this problem, make sure that you work on experiments or prototypes in isolated environments. Additionally, make sure that you preserve your official development environment for changes that you know will be promoted to test and production.
Test environment
The test environment is where you and your users should do all testing, such as integration testing and user acceptance testing. In the test environment, you should have a selection of data where you can do testing. This selection can be part of the data that you have in the production environment, or you can create your own test data that’s anonymized and can be used for testing. No customization should ever be done in a test environment. The solution from the development environment is promoted to test, and then you can do all the testing. If you find anything in the test environment that doesn’t work, you’ll need to make those changes in the development environment, not directly in the test environment.
Production environment
The production environment is where the users will do their daily job. Consequently, no change, piece of code, or configuration should ever be made in a production environment. If you find bugs in a production environment, you’ll need to return to your development environment, make the change, move the solution to the test environment, test it, and then move it on to the production environment. The production environment will naturally have all real, live data. Environments are administered in the Power Platform admin center. When environments are created, you’ll choose key characteristics, such as the geographic location and type of environment. You might encounter the following environment types:
- Default
- Developer
- Sandbox
- Production
The technical structure of the different types of environments is the same whether you create a sandbox environment or a production environment. Some differences exist between how a sandbox environment and a production environment behave and what administrative choices you have.
When moving customizations from the development environment to test and production, you can do so by exporting and importing solutions. Your solutions will contain all your customizations, such as tables, columns, Power Automate flows, and many more. The data that you’ve entered in to the system isn't added to solutions. Two types of solutions are managed and unmanaged. Your development environment will consist of mostly unmanaged solutions.
Unmanaged solutions are where you can make changes to the system. If you delete an unmanaged solution from a system, then the components within that solution won’t be removed from the environment. Managed solutions will be in your test and production environments. These solutions are locked, so you can’t effect changes to these solutions. This approach fits well with the environment strategy of only making changes to the system in the development environment. If you delete a managed solution from a system, then all components in this solution will also be deleted from the system.