Warning
🚧 Work in Progress: This page is currently under construction. Content may be incomplete or subject to change. To contribute, see the contribution guide.
Staging Environment
The staging environment mirrors production as closely as possible and is used for UAT, integration testing, and final validation before go-live.
Access
| Resource | Access method | Who |
|---|---|---|
| GCP project (staging) | Entra ID SSO | Squad members + business testers |
| Systems under test | Per-system credentials | Business owner + QA team |
| Deployment | GitHub Actions (main branch) | Squad lead approval |
Key URLs and endpoints
| System | Staging URL / endpoint |
|---|---|
| (fill in) | (fill in) |
Rules for staging environment
- Production-like data: staging should use an anonymized copy of production data, refreshed (fill in frequency — e.g., weekly)
- No direct database access by developers — go through the application layer
- Deployments to staging are triggered by merges to
main(orstagingbranch, per repo convention) - UAT sign-off is required before promoting to production — see Acceptance Criteria
Data refresh procedure
(Fill in how and when staging data is refreshed from production.)
Performance and load testing
Before any go-live that touches a performance-sensitive path:
- Load test executed against staging (not production)
- Results reviewed by the squad lead
- Any degradation vs. baseline investigated and resolved