3 ms·
Deployment ordering at large scale is avoided and usually done by not making breaking changes. 4 phase migrations, always. Roll out new API, update existing sof
by ecnahc515 7y ago
Deployment ordering at large scale is avoided and usually done by not making breaking changes. 4 phase migrations, always. Roll out new API, update existing software to use new API, wait for everything to stop using old API + backfill, remove old API.
- erik_seaberg 7y agoI agree that gradual adoption of new APIs is the way to go, but once you're doing that you no longer need an atomic commit across all projects.
- dehrmann 7y agoYou actually never want an atomic commit for that class of changes across projects because HEAD should always be deployable to all services. It's obviously messier at FAANG-scale, but with even 25 devs, not properly staging API-breaking changes leads to a lot of "only deploy commits before xxxx to service foo."