CI/CD for a containerized app: CodePipeline, CodeBuild, and ECS
How one git push becomes a new container running behind your load balancer, and how the pipeline puts the old one back when the new one misbehaves.
The pipeline as a conveyor belt
A container CI/CD pipeline on AWS is three ordered stages that AWS CodePipeline runs end to end: Source, Build, and Deploy. The Source stage watches a repository (for example AWS CodeCommit). When a developer pushes a commit, CodePipeline detects the change automatically and starts an execution, moving an artifact from one stage to the next.
The Build stage runs AWS CodeBuild, which is where the container image is actually produced. CodeBuild spins up a fresh managed build environment, reads a buildspec.yml file from the repository root, and runs the phases you declared in it. The Deploy stage then takes CodeBuild's output and updates the Amazon ECS service so new tasks run the image that was just built. Nothing in the middle is manual: a commit is the only human action in the loop.
CodePipeline conveyor belt: Source, Build, Deploy
Trace
One git push starts an execution automatically. CodePipeline moves an artifact through three ordered stages: Source pulls the commit, Build runs CodeBuild, Deploy updates the ECS service. Each stage reads its input artifact and writes its output artifact to a managed S3 bucket.
Building and storing the container image
CodeBuild's buildspec.yml declares ordered phases. The install phase prepares tooling; the pre_build phase authenticates Docker to Amazon ECR (running aws ecr get-login-password and piping it to docker login) so the build can push to a private registry; the build phase runs docker build to create the image and runs the unit tests; and the post_build phase runs docker push to send the tagged image to Amazon ECR. Amazon ECR is the artifact registry that holds the versioned image between build and deploy.
Because a raw image in ECR does not by itself tell the Deploy stage which container to update, the standard ECS deploy action consumes an imagedefinitions.json file that CodeBuild writes as an output artifact. That file maps a container name to the exact image URI (including the tag or digest) that the ECS service should run. Running the unit tests inside the build phase means a commit that breaks the tests fails the Build stage and never reaches Deploy, which is how automated testing is wired into the pipeline itself.
Inside CodeBuild: buildspec phases, ECR, and imagedefinitions.json
Trace
CodeBuild spins up a fresh managed environment and runs the buildspec.yml phases in order. pre_build authenticates Docker to ECR, build runs docker build and the unit tests, and post_build runs docker push and writes imagedefinitions.json (container name to image URI) as the output artifact the Deploy stage consumes.
Deploying to ECS: rolling versus blue/green
There are two deployment strategies to move the new image into the running ECS service. A rolling update is the ECS-native strategy: ECS replaces tasks in batches, governed by the service's minimumHealthyPercent and maximumPercent settings, so a portion of tasks stays in service while the rest are cycled to the new task definition. It is simple and needs no extra components.
A blue/green deployment is run by AWS CodeDeploy and shifts traffic between two target groups behind the load balancer: the new (green) task set is stood up alongside the old (blue) one, traffic is shifted to green, and blue is kept briefly so rollback is instant. The CodeDeploy blue/green deploy action does not use imagedefinitions.json; instead it consumes an appspec.yaml plus a task definition file. Its biggest advantage is safety: you can attach a CloudWatch alarm to the deployment so that if the new tasks start erroring, CodeDeploy automatically rolls the traffic back to the blue task set instead of leaving a broken release live.
Deploying to ECS: rolling update vs CodeDeploy blue/green
Trace
Two strategies to move the new image live. The ECS-native rolling update replaces tasks in batches governed by minimumHealthyPercent and maximumPercent. CodeDeploy blue/green stands up a green task set beside blue, shifts traffic between two target groups, and rolls back to blue automatically if a CloudWatch alarm fires.
What this teaches for the exam
Two artifact-file facts are the ones exam questions hinge on: the standard ECS rolling deploy action needs an imagedefinitions.json (container name to image URI), while a CodeDeploy blue/green ECS deployment needs an appspec.yaml plus a task definition. Mixing these up is the classic distractor.
Beyond the files, remember the shape: Source triggers automatically on commit, CodeBuild is the only place the image is built and tested (put unit and integration tests here so a bad commit fails before Deploy), Amazon ECR is the versioned image store, and blue/green with a CloudWatch alarm is the answer whenever a scenario asks for automatic rollback on failure. Each stage should run under its own least-privilege IAM service role rather than one shared admin role.
Exam shape: artifact files and least-privilege stage roles
Trace
The two facts exam questions hinge on: the standard ECS rolling deploy action consumes imagedefinitions.json, while a CodeDeploy blue/green deployment consumes appspec.yaml plus a task definition. Each stage runs under its own least-privilege IAM service role, and blue/green with a CloudWatch alarm is the answer for automatic rollback.
