TELEICU/Change management
From OHC Network Wiki
More languages
More actions
Process for planning, reviewing, and deploying changes across the TELEICU fleet.
Change lifecycle
{{#mermaid:flowchart LR
PLAN["Plan<br/>(RFC document)"]
PR["Pull Request<br/>(git)"]
REVIEW["Review<br/>(peer + hub admin)"]
STAGING["Staging<br/>(test env)"]
CANARY["Canary<br/>(1-2 sites)"]
ROLLOUT["Regional Rollout"]
DONE["Fleet-wide"]
PLAN --> PR
PR --> REVIEW
REVIEW --> STAGING
STAGING --> CANARY
CANARY --> ROLLOUT
ROLLOUT --> DONE
CANARY -->|"fail → revert"| PLAN
ROLLOUT -->|"fail → pause"| PLAN
}}
Change types
| Type | Review required | Staging | Canary | Rollout window | |---|---|---|---|---| | Security patch | Light (1 reviewer) | Yes | 1 site | Within 7 days | | Bug fix | Normal (2 reviewers) | Yes | 1 site | Next business day | | Feature/middleware update | Full (2 reviewers + hub lead) | Yes | 2 sites | Scheduled window | | OS update (NixOS flake) | Full (2 reviewers) | Yes | 2 sites | Quarterly | | Hardware change | Site-specific | N/A | N/A | As needed | | Emergency patch | Post-hoc review | Bypassed | Bypassed | Immediate |
RFC template
Every change should document:
- What is changing and why
- Risk assessment — what could break
- Rollback plan — how to undo
- Impact scope — which sites/nodes are affected
- Testing performed — what was validated in staging
- Monitoring — what to watch during rollout
Approval gates
- Peer review (code/infra team)
- Hub admin sign-off (if clinical impact is possible)
- Ops lead approval for fleet-wide rollout