Deploy vs release

A deploy puts new bits on servers. For a container platform, that means registering a new revision or updating a Deployment's image. A release makes those bits serve behaviour that users can see. The two events can happen at different times, and treating them as one event is how risky launches happen.

Walking through the levers

Each lever controls something different, and each one rolls back in its own way.

A safe sequence looks like this. Deploy the new code with its flag off. Check process health and error rates, which should not change. Turn the flag on for 1% of users. If the signals stay green, widen it. A broken flag is switched off in seconds. The deploy itself was never user-visible.

Flags and traffic are different tools

Use flags for behaviour, and traffic shifts for binary risk. A flag cannot fix a binary that crashes on start. The crash happens before any code path is chosen, so only a revision or traffic rollback helps. For high-stakes changes, use both.

Common mistakes

• Treating a deploy as a launch. Every merge then becomes a big event.
• Using a flag for a crashing binary. The flag is never reached.
• Deleting the old revision too early. Then there is nothing to roll back to.

Check yourself

1. A new build crashes at startup, and its flag is off. Can the flag fix it? Answer: No. The crash happens before any code path is chosen, so you need a revision or traffic rollback.
2. What does a traffic split control? Answer: Which copy of the binary each request reaches. Rolling back means shifting the weight to the old copy.

Key takeaways

• A deploy puts bits on servers. A release changes what users see.
• Flags control behaviour inside a binary. Traffic splits control which binary serves.
• Use both for high-stakes changes, and keep the previous revision until the new one is proven.

Further learning

Next, see the main ways to shift traffic from one version to another: rollout strategies.