IFO4
Loading...A deployment technique in which a new version of a service is exposed to a small, increasing fraction of production traffic, with continuous evaluation of error rate, latency, and business metrics against the prevailing baseline, and with automated rollback on regression. The canary is not a marketing surface; it is a control surface for limiting blast radius during change. The federation requires that canary criteria be declared before deployment and that the rollback decision be automated whenever possible under UFMS-001:2.4.
Borrowed from the practice of taking a canary into a coal mine to detect carbon monoxide; entered software deployment vocabulary through Google's site-reliability engineering literature in the early 2010s.
Federation members operating canary releases must publish their gating criteria, observation windows, and rollback automation. Manual-only rollback for Tier-1 services is reported as a finding under MEV-Annex:3.2.
@misc{ifo4_glossary_canary_release,
title = {{Canary Release}},
author = {{IFO4 Federation Editorial Board}},
howpublished = {{IFO4 Federation Glossary, slug \texttt{canary-release}}},
year = {2026},
url = {https://ifo4.org/glossary/canary-release},
note = {Category: DevOps; key: CanaryRelease}
}Federation members and accredited practitioners may challenge any entry under TGS-002:1.7. Filed challenges are routed to the editorial board, triaged into the revision register, and resolved in writing on the public docket. The slug remains stable through any revision.