# Dev / Test / Prod Environment & Release Framework

**SyncMate — WYHEN Pty Ltd (ABN 57 688 078 999)**
Version 1.0 · Effective 31 August 2026 · Owner: Founder/Technical Operator · Review: annually

## 1. Purpose

Defines the environments a change passes through before reaching customers, the gates at each stage, and the separation between them — so that technical vulnerabilities and defects are caught before production and so that no environment can reach another's data.

## 2. Environments

| | Development | Preview (Test) | Production |
|---|---|---|---|
| Purpose | Building and unit-level verification | Functional, access-control and integration verification | Live customer service |
| Hosting | Local workstation | Deployed, isolated from production | Deployed, customer-facing |
| Database | Isolated development database | Separate preview database | Production database |
| Data | Synthetic and non-production data only | Synthetic and non-production data only | Real customer data |
| Credentials | Development-only secrets | Preview-only secrets | Production-only secrets |
| Xero | Xero demo organisation | Xero demo organisation | Customer-authorised organisations |
| Payments | Stripe test mode | Stripe test mode | Stripe live mode |
| Access | Developer | Developer and, on request, customer assessors | Operator only; customers via the application |

**Separation rules.** No environment shares credentials, database connections or secret values with another. Production credentials are never present on a development workstation or in the preview environment. **Production customer data is never copied into development or preview** — where realistic data is needed, synthetic data is generated. A restore of a production backup for testing is made into an isolated staging database, is not connected to the preview application, and is destroyed after the test.

## 3. Promotion path and gates

```text
Development --[gate 1]--> Preview --[gate 2]--> Production
```

**Gate 1 — before deploying to Preview**
- [ ] Change is on its own branch and linked to a tracked item.
- [ ] Code review completed against the A3 §5 checklist.
- [ ] Type-check, lint and build pass.
- [ ] Automated dependency and code security scan shows no Critical or High findings.
- [ ] Database migrations reviewed and include access policies and grants for any new object.
- [ ] Threat-model note present where the change touches authentication, tenant isolation or file handling.

**Gate 2 — before promoting to Production**
- [ ] Functional verification of the change performed in Preview.
- [ ] Access-control verification where the change touches data access: confirm a user of one workspace cannot see another's data on the affected path.
- [ ] Migrations applied successfully in Preview with no errors.
- [ ] No new errors in Preview logs attributable to the change.
- [ ] Rollback target (the preceding release) identified.

## 4. Release and rollback

Releases are continuous — typically several per week — and are rolling, requiring no planned downtime. Every release is a redeployable changeset traceable to the code and migrations it contains. Rollback is by redeploying the immediately preceding release, with a target of under 1 hour. Where a destructive migration is unavoidable, a database backup is taken immediately before it is applied.

## 5. Emergency changes

A Critical security fix may bypass the Preview stage only where delay would leave customer data exposed. It requires: a documented rationale, the standard code review, and same-day verification in production plus a retrospective recorded in the vulnerability register (A6).

## 6. Traceability

For each production release we retain: the changeset, the reviewer, the gate results, the migrations applied, the deployment timestamp and the identity of the deployer. Records are retained for at least 3 years and are available to customers as evidence on request.

## 7. Customer assessment access

Enterprise customers may be provisioned a dedicated workspace for their own functional and security assessment, including connecting their own Xero demo organisation. Automated or aggressive scanning and load testing must be scheduled with WYHEN and directed at that workspace rather than run unannounced against live tenants. Findings are accepted and triaged under A6.