Deployment patterns and environment strategy

What it does

Environment strategy is the decision about how many environments a tenant has, what each is for, and how work moves between them. In practice it's the separation of where things are built from where they run, plus the governance settings that keep makers inside the lines.

Key facts

Environment types are Default, Production, Sandbox, Developer, Trial, Dataverse for Teams, and Support. Trial, preview, support and developer environments don't count against tenant capacity; default, production and sandbox do.
Makers can have up to three developer environments. Developer environments unused for 90 days are turned off and then removed if the owner doesn't respond to notifications. Dynamics 365 apps aren't available in them.
The default environment ships with every tenant and Microsoft is explicit that it isn't intended for long-term or permanent work beyond Microsoft 365 personal productivity scenarios.
Default environment routing redirects makers into a personal developer environment instead. Environments created that way are Managed by default, and makers become environment admin of their own.
Environment groups apply rules — sharing controls, solution checker enforcement, backup retention, usage insights, maker welcome content — across a set of environments. An environment must be Managed to join a group, and can be in only one group.
When a group rule manages a setting, the individual environment setting is locked. An environment admin can't override it; only a group rule change can.
Production Managed Environments support extended backup retention from seven days up to 28.
Whether Dynamics 365 apps are enabled must be decided at environment creation. You can't add it later.
Every environment consumes 1 GB of capacity whether or not it has a database.
Solution checker enforcement has three levels: None, Warn, Block.

When to use / skip

Three environments — dev, test, production — is the floor for anything a business will depend on, and it's rarely worth arguing below that. Per-maker developer environments are worth the setup on any tenant with more than a handful of makers, because the alternative is everyone building in the default environment and nobody being able to untangle it later. Where you can be pragmatic is the test tier: a single shared sandbox is usually enough, and separate UAT and SIT environments are worth having only when there are genuinely separate testing groups with conflicting data needs.

Configuration decisions

How many tiers, and whether test and UAT are the same environment wearing two hats.
Whether developer environments are per maker via routing, or a smaller number of shared team sandboxes.
Whether manual creation of developer environments is disallowed in tenant settings and routing is restricted to a security group.
Environment group structure and which rules are locked at group level, since that removes the setting from environment admins entirely.
Solution checker enforcement per tier — the common pattern is Block on default and production, Warn on developer and sandbox.
Sharing limits per tier, and whether sharing with security groups is excluded.
Whether Dynamics 365 is enabled at creation, which is irreversible.

Gotchas

Sharing limits only apply to future sharing. Applying a limit to an environment where things are already shared more widely changes nothing for existing shares, and you need a separate process to bring those back in line.
Developer environments disappearing after 90 days of no use is a real risk for a paused project. If the work isn't in source control it's gone.
Default environment capacity is reported oddly — the list view shows only usage above the included quota, so an environment showing near-zero may not be.
Forgetting to enable Dynamics 365 at creation is a rebuild, not a setting change.
Trial environments are automatically removed after a short period. They aren't a place to build anything you want to keep.
Managed Environments require premium use rights for users in them, so environment strategy and licensing can't be designed separately.
Promoting a solution built without a preferred solution set usually means promoting the default solution, which is why those makers can't cleanly hand work over.

Consultant notes

Get default environment routing and a preferred solution policy in place before the maker community grows. Retrofitting it is a migration exercise nobody funds.
Environment groups are the lever that makes governance stick, because they take settings away from environment admins rather than asking them nicely. Frame that as reduced admin effort rather than reduced autonomy.
Warn about the 90-day developer environment expiry explicitly in any project that has a pause built into the plan.
Tie the environment design to the licensing conversation in the same workshop. Managed Environments, premium use rights and the number of production environments are one decision, and clients who split them get an unpleasant surprise at renewal.
Maker welcome content is underrated. A paragraph explaining what an environment is for prevents a surprising amount of misplaced work.

Worth revisiting if developer environment limits change, or after the next release wave adds group rules.