- 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
1.7 KiB
1.7 KiB
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.