Reliability
Part of Cloud deployment workflows
Testing a deployment before changing live services
Choose release checks around changed components, important user actions and explicit pass conditions before changing live services.
Test the production release candidate against the user actions and dependencies the change could affect. Set pass conditions first, run relevant checks in a suitable environment and record their coverage. A passing unit test or healthy server alone cannot prove a live business action will work.
Start with the change and its likely failure
List every code, configuration, infrastructure, schema, permission and integration change. For each, ask what could fail and which check would reveal it. A changed API field may need a contract check; a changed database query needs representative data and performance conditions; a new network rule needs an authorised check of the intended access path.
Keep a release test record showing candidate version, environment, data conditions, expected outcome, owner and result. Mark each check pass, fail or unassessed after it runs. A planned check is not a pass.
Layer the checks
Fast code checks can catch logic errors before deployment. Integration checks exercise interactions with databases or other services. Select end-to-end checks that complete important user actions through the deployed candidate. Add performance, security or resilience checks when the change or workload calls for them.
| Change | Proposed check | What a pass would still leave open |
|---|---|---|
| Application logic | Relevant unit and critical-action regression checks | Untested integrations and live traffic |
| Database schema | Old and new application versions against the proposed schema | Live data shape and migration duration unless represented |
| Network access | An authorised client reaches the service; an unwanted path remains restricted | Other networks and identities not included in the check |
| Capacity setting | A representative busy-period action with resource observation | Demand beyond the modelled workload |
These are test-design prompts, not reported results. Adapt them to the application and define an expected result for each.
Test Check Types and What They May Miss
- Application logic
- Unit and regression checks on critical actions
- Database schema
- Old and new app versions tested against proposed schema
- Network access
- Authorised client reaches service; unwanted paths remain restricted
- Capacity setting
- Representative busy-period action with resource observation
Make the conditions credible
Use the deployment method, permissions, configuration and dependency versions that matter to production. Document any intentional differences. Synthetic data is a useful default, but it must represent edge cases and volumes relevant to the change. If a necessary case uses production-derived data, arrange suitable protection and approval before copying it.
Include scheduled work and retries where they affect the changed path. A web request may pass while its background job fails later. If an external system cannot safely receive tests, record the substitute and leave the real integration unassessed until a suitable check is available.
Make the release decision
Review results against the agreed pass conditions before live deployment. Hold or revise the release if a critical action fails or a material check has no decision owner. An owner may accept an unassessed item with a stated production observation and response plan; its label should remain unassessed.
Identify what will be watched after exposure: completed actions, errors, latency and a signal specific to the change. Limited production exposure can reveal conditions absent from test, but it affects real users and needs a stopping rule. Record the candidate version and observations so any later failure can be tied to the release.
Key Metrics to Monitor Post-Release
- Completed actions
- Track success rate of key user journeys
- Errors
- Monitor error rates and stack traces
- Latency
- Measure response times under real load
- Change-specific signal
- Define and track a metric unique to the deployment change
