Amazon Web Services

CI/CD — CodePipeline, CodeBuild & CodeDeploy

Release on AWS with CodePipeline, CodeBuild and CodeDeploy so every deployment shifts traffic gradually and rolls itself back when an alarm fires.

On AWS the release question is less "what is CI/CD" than which of AWS's deployment mechanisms you would use, and what reverses a bad release without anyone being paged.

A restaurant trying a new recipe on one table in ten while the old recipe stays on the stove. If that table starts sending plates back, the kitchen quietly returns to the old recipe for everyone — no announcement, no chef woken up.

Key Concepts

1
    source -> CodeBuild -> artifact -> CodeDeploy (staging) -> approve -> CodeDeploy (prod)
    GitHub /   buildspec.yml   S3 / ECR    traffic shifting        manual      alarms watch it
    GitLab via CodeConnections
2
CodePipeline sequences the stages and stops on failure. Its V2 pipeline type adds triggers filtered by branch, tag or changed file path, so a monorepo can run only the pipeline whose code changed. CodeBuild runs each build in a fresh container defined by buildspec.yml, under an IAM role, so no credentials live in the build.
buildspec.yml
3
CodeDeploy is where the strategy lives, and its deployment configurations differ by compute platform:
4
    EC2 / on-prem   in-place, by batch: AllAtOnce, HalfAtATime,
                    OneAtATime -- or blue/green behind a load balancer
    ECS             blue/green between two target groups; canary or
                    linear traffic shifting on the listener
    Lambda          alias shifting: Canary10Percent5Minutes,
                    Linear10PercentEvery1Minute, AllAtOnce
5
Automatic rollback is the point. Attach CloudWatch alarms — error count, p99 latency — to the deployment group; if one fires while traffic is shifting, CodeDeploy routes everything back to the previous version. Lifecycle hooks such as BeforeAllowTraffic run a test against the new version before it receives a single real request.
BeforeAllowTraffic
6
Two versions serve at once during every shift, so a schema change has to be safe for both: add the new column first, release the code that uses it, and drop the old column in a later release.
7
ECS now also offers built-in blue/green deployments without CodeDeploy; for Lambda, SAM's DeploymentPreference wires the alias, the alarms and the hooks for you, as in the example.
DeploymentPreference
8
Promote one artifact. CodeBuild produces a single image or package that every stage deploys; rebuilding per environment would mean shipping something other than what was tested.
9
What the interviewer is probing.1. "A Lambda release starts erroring at 10% of traffic. What happens if it was deployed well?" Probing: alarm-driven rollback. Stalls: "Someone rolls it back." Moves up: the deployment used a canary configuration with a CloudWatch alarm attached, so CodeDeploy moves the alias back to the previous version automatically and only a tenth of traffic saw the fault.
10
2. "How does a blue/green ECS deployment work under CodeDeploy?" Probing: the mechanism. Stalls: "It starts new containers." Moves up: a replacement task set registers in a second target group, test traffic can be routed to it first, then the load balancer listener shifts production traffic over — and back, if an alarm fires.
11
3. "Your monorepo triggers every pipeline on every commit. How do you fix it?" Probing: CodePipeline V2. Stalls: "Split the repository." Moves up: V2 pipeline triggers can filter on file paths and branches, so each pipeline starts only when its own code changes.
12
4. "What runs before real users reach a new version?" Probing: lifecycle hooks. Stalls: "The unit tests." Moves up: a BeforeAllowTraffic hook — a Lambda that exercises the new version — must succeed before CodeDeploy shifts any production traffic to it.
BeforeAllowTraffic