Plan environments for an agent's lifecycle
Releasing each agent update in the same controlled way depends on keeping the version you build, the version you test, and the version people use in separate places. In this unit, you learn how to choose an environment type for each lifecycle stage, plan for the environments that pipelines require, and secure each environment with a security group.
Define the lifecycle stages
A Power Platform environment is a separate container for agents, apps, flows, connections, and data. An ALM plan for an agent includes at least three environments, one for each lifecycle stage:
- Development: Makers build and change the agent.
- Test: Testers validate a candidate version of the agent before it reaches users.
- Production: People use the released agent.
Changes move through these stages in one direction. After you change the agent in development, you promote it to test. When testers find a bug, you fix it in development and promote the agent again. For example, if testers report that an HR agent your team built gives an outdated answer about leave policy, you correct the agent in development and send the corrected version back through test. After testing passes, you deploy the agent to production.
The one-way flow depends on a core rule: don't customize the agent outside a development environment. A fix made directly in test or production skips validation.
Three environments are the minimum. Add more stages when your release process needs them. For example, you might add an environment where a subset of users tries the agent before you share it with everyone.
Match an environment type to each stage
Every environment has a type that indicates its purpose and determines its characteristics. Use a production type environment for the production stage, and use sandbox type environments for development and test. Other types have narrower roles in a lifecycle plan, or none.
| Environment type | Fit in an agent's lifecycle |
|---|---|
| Production | The production stage. Production environments are intended for permanent work and for any environment your organization depends on. |
| Sandbox | Development and test. Sandboxes are nonproduction environments that support operations such as copy and reset. |
| Developer | One maker's development work. A user with the Developer Plan creates this environment, and it's intended only for its owner. |
| Trial | Short-term evaluation. A trial environment expires after 30 days, which rules it out for a stage that must last across releases. |
| Default | No lifecycle stage. |
The default environment needs an explicit decision in your plan. Each tenant has one default environment, created automatically and shared by all users in the tenant. Every licensed user has the environment maker role there. The default environment is intended for experimentation and personal productivity, and it shouldn't hold production workloads. Keep it out of your agent's lifecycle. Build the agent in a dedicated development environment, and deploy it to a production environment other than the default one.
Plan for pipeline requirements
Pipelines in Power Platform automate moving an agent from development through each later stage. A pipeline adds one more environment to your plan: the pipeline host. The host holds the pipeline configuration and keeps a copy of each version it deploys. Plan the host with these requirements:
- Type: Use a production type environment for the host.
- Separation: Keep the host separate from development. Using the same environment as the host and the development environment isn't supported. Using the host as a test or production stage isn't recommended either.
- Geography: Place the host in the same geography as every environment its pipelines use. Deployments across geographies work only when the Cross-Geo Solution Deployments setting is enabled in the host.
- Single host: Associate each environment with only one host. An environment can still belong to several pipelines in that host.
Pipelines also determine which environments must be managed environments. A managed environment is one where an admin enables Managed Environments, a suite of premium capabilities for governing the environment with more control and insight. The capabilities include sharing limits, usage insights, solution checker, and pipelines. Admins can enable Managed Environments on any environment type, and every managed environment requires licenses that grant premium use rights. The following table shows the type and managed environment requirement for each environment in a pipeline plan.
| Environment | Environment type | Managed environment |
|---|---|---|
| Development | Sandbox, or developer for one maker | Required for a sandbox, not required for a developer environment |
| Test | Sandbox | Required |
| Production | Production | Required |
| Pipeline host | Production | Not required |
Enabling Managed Environments requires the Power Platform Administrator or Dynamics 365 Administrator role, so your plan names the admin who does it. Tenant admins can also automate this step. In the Power Platform admin center, under Deployments > Settings, they turn on a setting for a pipeline host that makes every environment its pipelines deploy to a managed environment.
Secure each environment with a security group
Environment type and managed status determine what an environment can do. A security group determines who can use the environment. Associate a Microsoft Entra security group with each sandbox and production environment in your plan, so that only licensed members of the group become users there. A Power Platform Administrator or Dynamics 365 Administrator makes the association in the Power Platform admin center.
After you associate the group, membership drives access:
- Adding a user to the group adds them to the environment, and removing a user disables them there.
- Associating a group with an environment that already has users disables every user who isn't a member. Confirm the group's membership before you associate it.
- Members still need at least one security role in the environment before they can access its data.
- Application users, which an admin creates for a Microsoft Entra app registration, run in a secured environment without group membership.
Plan each group around the work its stage supports. In development, makers need environment maker access to create resources. In a sandbox used only for testing, testers need only user access. You can't assign a security group to default or developer environments. Use sandbox and production environments for any stage where you need to control who has access.
With an environment planned for each stage, the agent and its dependencies need a package that can move between those environments.