Reliability
Part of Cloud deployment workflows
Separating development, test and production environments
Set boundaries for cloud development, test and production while keeping test results relevant to a live release.
Keep development, test and production separate so experiments and test activity cannot casually change live services or data. Make test comparable enough to production for its results to inform a release. A different target name in a deployment tool is only one part of the boundary.
Give each environment a job
Development is where a team changes and inspects software. Test holds a candidate for automated checks, integration work or user acceptance. Production serves live users and holds the authoritative live state. Staging can provide a final check against a configuration close to production when that extra stage is useful.
Record who and what may deploy, read data and change resources in each environment. Use separate deployment identities and permissions where supported. Access needed to reset test data should not automatically grant the same action in production.
Make the resource boundary real, not just a label. In Azure, subscriptions provide a management boundary for governance and isolation, and they serve as the boundary for Azure Policy assignments. Placing production in its own subscription lets development carry more relaxed policy requirements without weakening production controls.
Environment Boundary Best Practices
- Assign clear roles to each environmentDevelopment: code changes. Test: validation. Production: live service.
- Use separate subscriptions for productionEnables strict governance and policy control via Azure Policy.
- Isolate secrets and credentialsEach environment must have its own Azure Key Vault or equivalent.
- Document shared dependenciesRecord ownership, access controls, and safeguards for shared resources.
- Apply Australian Privacy PrinciplesProtect personal information in test data; de-identify or destroy when no longer needed.
Draw the boundary around dependencies
Inventory the databases, storage, queues, scheduled jobs, identities, external integrations and network endpoints each environment uses. Shared resources can create a path from a test action into live operations. A test order sent to a live fulfilment connection, for example, could have a real effect even if its web server is labelled test.
For a shared dependency, record why it is shared, who owns it and what prevents test traffic or writes from affecting production. Check that control before relying on the boundary. In Azure, virtual networks can't be shared across subscriptions; any link, such as virtual network peering or ExpressRoute, is a deliberate connection to document.
Use synthetic or suitably protected test data. If a necessary case uses production-derived personal information, Australian Privacy Principle 11 still applies: the organisation must take reasonable steps to protect it from misuse, interference and loss, and from unauthorised access, modification or disclosure, and destroy or de-identify it when no longer needed.
Keep live credentials out of development and test. Give each environment its own secret store, such as a separate Azure Key Vault, a cloud service for securely storing API keys, credentials and certificates, and let only that environment's pipeline read it.
Azure Environment Governance Metrics
- Separate Subscriptions Used
- Recommended for production isolation
- Policy Enforcement Enabled
- Azure Policy applied at subscription level for compliance
- Virtual Network Isolation
- Not shared across subscriptions without explicit peering or ExpressRoute
- Secret Store per Environment
- Each environment uses its own Azure Key Vault
- Protected Deployment Environments
- Required in GitHub Actions, GitLab, and Azure Pipelines
Keep important differences visible
Test need not match production's full capacity, but it should exercise the application contract, security policies and deployment path relevant to the release. Record intentional differences such as instance count, substitute services and smaller data volumes. Each difference limits what a pass proves.
| Difference | Question for the release |
|---|---|
| Smaller capacity | Which load or scaling question needs a separate check? |
| Mocked external service | Which real integration behaviour remains unverified? |
| Different access policy | Could production reject a deployment or user action that test allows? |
| Different data shape | Could a migration or query behave differently on live data? |
Infrastructure templates can reduce configuration drift, but their parameters and permissions still need review. Azure landing-zone guidance describes placing subscriptions in appropriate management groups and using policy-driven governance to manage application environments.
Key Differences Between Development, Test and Production Environments
- Environment PurposeDevelopment: Code changes and inspection. Test: Candidate validation. Production: Live user service.
- Access ControlsEach environment has separate deployment identities and permissions. Production access is strictly limited.
- Resource IsolationProduction in its own Azure subscription for governance and policy enforcement; development may have relaxed policies.
- Credential ManagementEach environment has its own secret store (e.g., Azure Key Vault). Live credentials never used in dev/test.
Check promotion and access
Before release, identify the version deployed to test, its results and the version proposed for production. Check that the production deployment identity has the required access and that test jobs cannot select the production target by accident.
If GitHub Actions environment rules are part of the plan, verify the repository's effective settings and plan. GitHub documents branch restrictions and required reviewers, but on GitHub Free, Pro and Team, required reviewers are available only for public repositories. A rule has to be configured; an environment name alone does not enforce approval.
Other pipelines have equivalents. In Azure Pipelines, a manual approval check on an environment ensures deployment only happens after the designated user reviews the changes, and checks are not defined in the YAML file, so pipeline editors cannot remove them. In GitLab, a protected environment lets only people with the appropriate privileges deploy.
Revisit the boundary when a new integration, shared service or deployment identity is introduced. A useful environment map shows each target, its data and external paths, permitted operators and the differences that limit test evidence.
Deployment Promotion Workflow with Environment Checks
- Deploy to TestVersion deployed to test with automated checks and UAT.
- Verify Test ResultsConfirm test outcomes meet release criteria before promotion.
- Validate Production AccessEnsure production deployment identity has required permissions.
- Manual Approval (if required)Use manual approval in Azure Pipelines or protected environments in GitLab.
- Deploy to ProductionFinal deployment only after all checks pass and access verified.
