Release Governance
Objective
Roadside releases should be predictable, reversible, and isolated from back-office release timing.
Branch Model
main
- production-ready branch
- no direct pushes
- highest review and security expectations
- production deployment triggered only through controlled workflow execution
staging
- integration and release-candidate branch
- used for end-to-end validation of ingest, device, and evidence pipelines
- automatically deploys to the staging environment after merge
Review Policy
staging
- minimum 1 approval when branch protection becomes available
- required status checks
- required conversation resolution
main
- minimum 2 approvals when branch protection becomes available
- required status checks
- required conversation resolution
- required code owner review
Zero-Downtime Principles
- use Kubernetes rolling deployments with
maxUnavailable: 0
- keep schema and contract changes backward-compatible during rollout windows
- separate deploy concerns from traffic bursts by keeping ingestion asynchronous
- keep rollback paths explicit through immutable image tags and environment-specific manifests
Operational Rules
- no shared-database coupling to the back-office platform
- no contract-breaking Kafka change without a versioned compatibility plan
- no production release while unresolved security or PII findings remain open