# Change Management Policy

**Effective:** 2026-03-15
**Owner:** Engineering

## Purpose

All changes to production systems follow a controlled process to prevent outages, data loss, and security regressions.

## Change Categories

| Category | Examples | Process |
|----------|----------|---------|
| **Standard** | Feature work, bug fixes, dependency updates | PR → review → CI → merge → deploy |
| **Expedited** | Security patches (critical/high) | PR → review → CI → merge → immediate deploy |
| **Emergency** | Active incident mitigation | Deploy first → PR + review within 24h |

## Pull Request Requirements

- All changes go through PRs. No direct commits to `main`.
- PRs require at least one approval.
- CI must pass: formatting, credo, dialyzer, sobelow, tests.
- PR description includes: what changed, why, how to test, rollback plan.
- Database migrations reviewed separately for data safety.

## Deployment

- Staging deployment first. Verify core flows work.
- Production deploy during business hours (preferred) unless emergency.
- Monitor error rates and key metrics for 30 minutes post-deploy.
- Rollback plan documented before deploying.

## Database Migrations

- Migrations must be backward-compatible (the old code must work with the new schema during rollout).
- No destructive migrations (DROP TABLE, DROP COLUMN) without a two-phase approach: deprecate → migrate data → remove.
- Large data migrations run as background tasks, not in the migration itself.
- Test migrations against a production-size dataset before deploying.

## Feature Flags

- New features behind feature flags when they affect core workflows.
- Flags default to off in production, on in staging.
- Remove flags within 30 days of full rollout.