Graham McIntie
26c7b0b993
- Commented out 'View RF Links' button in network map node detail panel - Commented out RF Link health legend (Good/Degraded/Critical) from map legend - Backend code (topology.ex) left intact per instructions - No RF tab found on device show page (nothing to hide there) - All tests pass, compiles clean with --warnings-as-errors Reviewed-on: graham/towerops-web#46
44 lines
1.7 KiB
Markdown
44 lines
1.7 KiB
Markdown
# 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.
|