graham/towerops
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
towerops/policies/CHANGE_MANAGEMENT.md
Graham McIntie 26c7b0b993 Hide RF Links UI elements from network map (TOW-44) (#46) 
- 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
2026-03-16 15:19:03 -05:00

1.7 KiB
Raw Permalink Blame History

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.