Deployments Checklist

Run through this list before opening an MR and again before merging to master. The flow is feature/* → dev → master.

Before opening an MR

• Branch follows the convention: feature/*, fix/*, refactor/*, etc.
• Target the dev branch, not master.
• Code style passes: zex ./vendor/bin/duster lint --dirty.
• Static analysis passes: zex ./vendor/bin/phpstan.
• Tests pass: zet. Add coverage for any new behavior.
• Migrations include a down() path, or are documented as one-way with a rationale.
• New columns either have a default or are nullable. Backfill plan documented for non-nullable adds against large tables.
• Activity log fires for any model change: prefer $model->update(...) over Model::where()->update(...) when the model uses LogsActivity.
• Feature flag wraps the change if the rollout is risky or partial. Default OFF.
• Translation keys added for any user-visible string.

Before merging to dev

• Pipeline is green.
• At least one approval from another engineer.
• Manual QA against staging if the change touches a customer-visible flow.
• If the deploy depends on another service shipping first (Volpe, Medusa, Castoro, Coniglio), the dependency is queued and the order is documented in the MR.

Before merging to master

• Verified on staging end-to-end.
• Database changes are reversible, or the rollback plan names a specific recovery path.
• If impersonation matters (admin-facing change), tested impersonating a non-super-admin too.
• Customer comms drafted for any user-visible breakage window.

After deploying to production

• Sentry shows no new error class for 30 minutes.
• Health checks (OhDear) green.
• Spot-check the affected endpoint or screen on production.
• If a feature flag was used, document the rollout plan (who turns it on, when).