If you look after what runs in production (the live version real people use), this page is for you. Real people do things your tests never tried. This page shows how Evolve tries a change on real traffic, meaning real people’s requests, a little at a time, what it watches for, and what happens when something’s off.
Why try it on real traffic
The only way to know how a change behaves in production is to try it there, carefully.
A canary, step by step
A canary is a new version given a small share of real traffic first, named after the canaries miners carried underground as an early warning.
Your project’s rules file, its policy, lists the steps. Say 10%, then 50%, then everyone. At each step:
- Evolve tells your platform (the system that runs your software, like Kubernetes or orchy) how to split traffic between the two versions, and checks that it really took effect.
- It waits for the observation window, the stretch of time it watches. Thirty seconds, for instance.
- It measures both versions over the same window: requests, errors and speed. Comparing the same minutes means a busy spell can’t be mistaken for a bad change.
- It compares the results with the guardrails, the limits set in your policy: a top error rate, a top latency (how long answers may take), and a limit on how much slower than the current version the new one may be.
A small step sees few requests, so it can have a longer window of its own: {percent: 5, observe_seconds: 60}.
Three possible answers
- Pass: on to the next step.
- Fail: roll back now.
- Unknown: not enough data, or the numbers weren’t available. Unknown never promotes. Your policy picks whether to wait one more window or roll back.
Promotion, then a health window
After the last step the new version takes all the traffic (that’s a promotion), and Evolve keeps watching for a while longer, the health window. Only then does it become the known-good version: the one Evolve will fall back to next time.
Evolve checks the rollback worked
Rolling back means putting the known-good version back and confirming it’s the one actually answering requests (see Where it runs for how).
And if Evolve can’t confirm that? It stops everything, locks the environment and raises an alert, so a person looks at it.
It never touches your main branch
Promotion changes what runs in an environment (a place your software runs, like production), and leaves your Git history alone. Merging the change into your main branch, the version of the code everyone works from, is still your call.
Next
Experiments: for when you want to know a change made things better.