Comparison
Deployment ringvsRelease train
Deployment ring
your own staff get it first, then the tolerant customers, then everyone, over about a week.
Grouping the audience into ordered cohorts by risk tolerance and releasing outward through them. It differs from a canary in that the cohorts are populations rather than percentages of traffic, so it works for things a canary cannot cover — desktop clients, mobile releases, tenanted systems. The first ring being your own organisation is the whole trick, since it converts customer-found bugs into staff-found ones.
Full entry →Release train
the release goes out on Thursday whatever is ready, and anything that missed it waits for the next one.
Shipping on a fixed schedule, with whatever has been merged and is ready, rather than when a particular scope is complete. It removes the negotiation about dates and makes cadence predictable, which is why it survives in mobile and in anything with an expensive release process. Its cost is batching — a fortnightly train makes every release a bigger, riskier change than a continuously-deploying team ever has.
Full entry →