Canary Release

A canary release is a deployment strategy in which a new version is exposed to a small portion of traffic, such as 1 to 5 percent, while the rest continues to use the stable version. The name comes from the canary in a coal mine: an early warning before the whole system is affected.

Why it matters

Testing never reproduces production perfectly. A canary limits the damage of a bad release to a few users, and real traffic reveals problems like rising error rates or slower responses. If the numbers stay healthy, the share is increased in steps until the new version takes over. If not, traffic is moved back quickly.

It requires good monitoring, a way to split traffic (a load balancer, ingress or service mesh), and a plan for database changes that work with both versions at once.

Example

Step 1:  v2 gets  5% of traffic, watch 15 min
Step 2:  v2 gets 25%, watch errors and latency
Step 3:  v2 gets 100%, retire v1
Abort if: 5xx rate or p95 latency exceeds the agreed threshold

Common mistakes

• Having no clear success criteria, so nobody knows when to proceed or roll back.
• Routing users randomly per request so one person sees both versions in a session.
• Making incompatible database schema changes.

Related

• Blue-green deployment
• Load balancer
• CI/CD
• Service mesh

यह पेज सामान्य जानकारी है, जिसे हमारी संपादकीय टीम ने लिखा है और दस्तावेज़ीकरण बदलने पर अपडेट किया जाता है। सर्वर और प्रदाता अलग-अलग होते हैं, इसलिए बदलाव पहले सुरक्षित तरीके से जाँचें। देखें: संपादकीय नीति और अस्वीकरण.