Templates › Environment and ALM strategy

Environment and ALM strategy

Format

Word (docx)

Owning skill

solution-architecture:environment-strategy

Tailored from

organisation, estate, constraints, edition, modules_in_scope, roles, generated_on

Status

draft

How to use this template

The solution architect ({{roles.solution-architect}}) drafts this strategy in Initiate with the platform administrator ({{roles.platform-administrator}}) and, where one exists, the release manager ({{roles.release-manager}}). It must be approved before the first sprint, because environments, the solution publisher and the pipeline are expensive to change once build has started. Review it at each stage gate and after any change to licences or capacity.

Guidance: The aim is simple: every change is made in development, held in source control, and reaches test and production only as a managed solution through a repeatable pipeline. Each section below should show how that holds for this project.

SMB: Three environments (development, test, production) and a simple pipeline are usually enough. Keep source control and managed solutions even when the partner is the only developer.

Enterprise only: Plan separate environments for SIT, UAT, training and pre-production, per-developer environments where the team is large, and pipeline approval gates owned by the release manager.

Document control

1. Context

{{organisation.name}} is delivering {{modules_in_scope}} as a {{edition}} project. Existing environments recorded in the profile: {{estate.environments}}. Licences recorded: {{estate.licences}}. Microsoft 365 tenant: {{estate.microsoft_365}}.

Guidance: Note any existing Dataverse environments, Power Apps or flows already in the tenant, and who owns them. Unmanaged makers' work in the default environment is common and should be inventoried before the project's environments are created.

2. Principles

• Development happens only in development environments; nobody customises test, UAT or production directly.
• Downstream environments receive managed solutions only.
• One publisher and prefix for the project's own components, agreed before the first component is created.
• Everything that varies by environment is an environment variable or connection reference, never a hard-coded value.
• Source control is the record of what was built; an environment can be rebuilt from it.

3. Environment inventory

Guidance: Choose the region to meet data residency needs for {{organisation.countries}} and any compliance constraints ({{constraints.compliance}}); confirm with the DPO or legal adviser where personal data is involved. Copying production into a sandbox brings live personal data with it, so agree masking or restricted access before doing so.

Enterprise only: Add pre-production for cutover rehearsal and performance testing, and consider separate developer environments per developer or workstream.

4. Solution structure

Guidance: Fewer solutions are easier to manage. Split only where release cadence or ownership genuinely differs, and never let two solutions modify the same component without a clear layering plan.

5. Source control and branching

Guidance: Name the repository, the branching model and who may merge. Solutions are exported and unpacked into source control on each change. Keep configuration data (for example queues, SLA settings, reference data) in source control too, packaged with the deployment.

6. Deployment pipeline

Guidance: Options include Power Platform pipelines, Azure DevOps or GitHub with the Power Platform tooling. Check current Microsoft Learn documentation for capabilities and prerequisites before choosing.

7. Environment-specific settings

8. Governance and capacity

Guidance: Describe data loss prevention policies for each environment, whether Managed Environments are used, who may create environments, and how the default environment is governed. Record storage capacity and how growth is monitored. Confirm licence and capacity entitlements with the Microsoft licensing guide or your partner; check current Microsoft Learn documentation for governance features.

9. Release waves and updates

Guidance: Describe how each release wave is tested before it reaches production: which sandbox receives early access, who runs the regression pack, and who decides whether issues block. Note organisation change freezes ({{constraints.change_freezes}}).

10. Access and administration

11. Approval

Credit: Template from D365Forge by Simon Foote and Robert Peledie (https://github.com/SimonFoote-greensparx/D365Forge), licensed under CC BY 4.0. Keep this credit when you share or adapt the template; in your own completed document you may keep it as a footer or remove it.