Déploiements sûrs avec déploiement canari et restauration

Switching all traffic to new code at once means a bug hits every user instantly. Progressive deployments shift traffic gradually so problems surface on a small slice first.

Publishing a Lambda creates an immutable version. An alias is a pointer (like live) you can move between versions, enabling controlled cutovers.

An alias can split traffic between two versions by weight, sending, say, 10% to the new version and 90% to the old.

A canary sends a small percentage of traffic to the new version, waits, then promotes the rest if healthy. CodeDeploy automates this for Lambda.

SAM exposes this via DeploymentPreference, choosing a canary or linear pattern.

A linear pattern shifts traffic in equal increments over time (e.g. 10% every minute), giving a slower, steadier rollout than a single canary step.

Attach alarms (error rate, latency) to the deployment. If an alarm fires during the shift, the deployment is considered failed.

When an alarm trips, CodeDeploy automatically moves the alias back to the previous version, restoring known-good code with no manual action.

Lifecycle hook Lambdas run before and after traffic shifts, letting you run smoke tests and abort the deploy if they fail.

Blue/green stands up a full second environment and switches over; canary shifts a percentage within one environment. For Lambda, weighted aliases make canary the simpler, cheaper default.

Deploy safely:

• Always deploy behind an alias
• Start with a small canary percentage
• Gate on meaningful alarms
• Run smoke tests in pre-traffic hooks

You learned progressive delivery:

• Versions are immutable; aliases point to them
• Weighted aliases and canaries shift traffic gradually
• SAM DeploymentPreference automates canary/linear patterns
• Alarms gate the rollout and trigger automatic rollback