← Back to Concept Contrast

Concept Contrast Fable

Start with a small batch and gradually roll out to users

Conclusion first:Canary deployment and canary release have almost the same name, but in engineering practice they point to different stages. Canary deployment focuses on deploying a new version to a small number of instances first, while canary release focuses on exposing a new version to a small portion of user traffic first. The former validates runtime stability, the latter validates user experience—the two are often chained in one release pipeline, but their monitoring priorities and rollback triggers differ.

Canary deployment and canary release have almost the same name, but in engineering practice they point to different stages. Canary deployment focuses on deploying a new version to a small number of instances first, while canary release focuses on exposing a new version to a small portion of user traffic first. The former validates runtime stability, the latter validates user experience—the two are often chained in one release pipeline, but their monitoring priorities and rollback triggers differ.

Fable

The winery tastes the first sip and the guest tastes the first pot

In the south of the city there was a century-old winery, and the winemaker had an ancestral rule: when new wine came out of the cellar, first pour a small cup and place it by the stove. After the time of two incense sticks, smell it for sourness and look for sediment. This was called the pre-stove test. Only if the pre-stove test showed no problem did they dare open the jar and fill the pots.

After opening the branch, the estate owner added a rule: for each brewed jug of wine, first send five jugs to the branch's most familiar regulars' tables, free of charge, and let the guests drink. After drinking, ask three questions: is the taste right, is the aftereffect strong, and does it cause a headache the next day. This is called the table trial. Only after the table trial is fully satisfactory is the new wine's label hung on the wine list the next day.

One year something went wrong. The new wine passed the stove-side check—standing by the stove, it looked clear and had no sour taste. They skipped the table test entirely and hung up the sign, putting it on shelves citywide the next day. The first day's customers all said it was good. By the third day, customers started coming back to return the wine—this batch gave them a headache and dry mouth the next day. What two sticks of incense by the stove could not detect, the customers detected after drinking and sleeping it off.

The estate owner closed the doors for three days and wrote the pre-stove test and the pre-table trial as two separate lines. The pre-stove test checked the stability of the wine itself—whether it would spoil, whether it had impurities, whether the alcohol content was correct. The pre-table trial checked the guest's experience after drinking—mouthfeel, aftereffects, and the body's reaction the next day. The two-incense-stick window and the overnight window were measuring completely different things.

As it grew, the estate owner realized there was another boundary to manage: how many jars should the kitchen-side test cover? Test one jar, and the other ninety-nine might have the same flaw. How many guests should the table-side test cover? Send five jugs to old acquaintances, and their tastes are fixed—they won't catch new problems. The owner raised the kitchen-side test from one jar to a sample of five, and the table-side test from five jugs to thirty, sent to different types of guests. Coverage and sampling strategy also had to be managed separately.

An out-of-town wine merchant came to learn. At the welcome banquet the estate owner drew a diagram: the check at the stove tests whether it runs—whether the wine keeps after being put in the jar. The check at the table tests whether it drinks well—whether guests are satisfied after actually drinking it. It must run before it can be drunk, but running doesn't guarantee it drinks well. The two things can't be reduced to one.

The winery later hung this diagram in the shipping room: new wine goes on the shelf after passing two gates—one at the stove, one at the table. Skip either gate, and you pay for it at that gate.

Canary deployment

Deploy the new version to a small number of instances first to verify whether the application itself can start normally, run, and respond to health checks. Focus on infrastructure and runtime stability, usually before user traffic is connected.

Canary release

Route a small portion of user traffic to the new version to validate user experience, functional correctness, and business metrics. Focus on user-side behavior and business data, after deployment validation passes.

Story Mapping

  • Stove-side verification: canary deployment, verifying whether a new version is stable in the runtime environment
  • At the table: canary release, validating the experience and business metrics of real user traffic
  • Skipping the pre-table trial and going straight to market: the typical incident of doing canary deployment without canary release
  • Two incense sticks vs. sleeping one night: the deployment validation window is short, while the release validation window must cover a complete user behavior cycle
  • Sampling five jars and thirty pots: deployment sampling covers the number of instances, release sampling covers the proportion of user traffic

Putting it into release process design

Canary deployment and canary release should be chained as two independent stages in the release pipeline. In the first stage, deploy to canary instances and monitor CPU, memory, error rate, and startup time—roll back without routing traffic if anything is abnormal. In the second stage, route a certain percentage of traffic to canary instances and monitor user-side metrics—business error rate, latency distribution, and key conversion rates—switch traffic back while retaining instances for troubleshooting if anything is abnormal. The two stages require different monitoring dashboards and rollback mechanisms with different trigger conditions.

京ICP备2026014272号