CI/CD Pipeline Configuration

Automate build → test → deploy with CodePipeline, and SAM/CloudFormation IaC.

If a developer had to manually upload to the server, run tests, and deploy every time they made a code change, it would be extremely tedious. CI/CD is the way to automate this entire process. You simply push your code to Git, and the rest — build, test, and deploy — happens automatically.

DVA-C02 exam questions in this area focus on how to automatically build, test, and deploy code changes.

 

What is CI/CD?

CI (Continuous Integration): Automatically builds and tests code every time multiple developers merge their changes. CD (Continuous Deployment): Automatically deploys code that has passed testing to a server.

In simple terms, it is a pipeline where code change leads to automatic test leads to automatic deployment, all in sequence.

 

AWS CI/CD Service Chain

AWS has dedicated services for each stage of CI/CD, all tied together by CodePipeline.

Source (CodeCommit/GitHub) → Build (CodeBuild) → Deploy (CodeDeploy) = Pipeline (CodePipeline)

 

CodeCommit

A Git-based source code repository. It is very similar to GitHub but fully managed within AWS. It supports branches, pull requests (PRs), code reviews, and event triggers.

CodeBuild

A fully managed build service. It is responsible for transforming code into executables or deployment packages (compiling, running tests, packaging, etc.). No server management required.

Build phases are defined in a buildspec.yml file. install: Install required tools and libraries pre_build: Preparation tasks before the build (Docker login, environment setup) build: Actual compilation and test execution post_build: Post-build tasks (sending notifications, tagging images) artifacts: Specify where to store the build output

CodeDeploy

Deploys the built code to actual servers. Code can be deployed to EC2 instances, Lambda functions, or ECS containers.

Deployment method is defined in an appspec.yml file. EC2/on-premises: Define hook scripts to run before and after installation Lambda: Define how much traffic to shift to the new version at a time (e.g., gradual 10% increments) ECS: Task definition and load balancer configuration

CodePipeline

Connects all the above services (source, build, deploy) into one unified, automated pipeline. Think of it as the conveyor belt of an automated factory.

Automatically links each stage: source → build → test → deploy Manual approval stages can be added when needed (e.g., a manager review before deploying to production) Integrates with EventBridge to automatically trigger the pipeline when specific events occur

 

SAM (Serverless Application Model)

SAM is a framework for defining and deploying serverless applications like Lambda using code (YAML files). Instead of clicking through the console to set up infrastructure, you define it as code — this approach is called IaC (Infrastructure as Code).

sam build: Builds the code and prepares a deployment package. sam deploy: Deploys to AWS via CloudFormation. sam local invoke: Tests Lambda functions on your local machine without deploying to AWS. Extremely useful during development. template.yaml: A configuration file that declaratively defines Lambda functions, API Gateway, DynamoDB tables, and more.

 

Exam Key Points

"File that defines build phases" -- buildspec.yml (CodeBuild)

"File that defines deployment method" -- appspec.yml (CodeDeploy)

"Source to Build to Deploy automation" -- CodePipeline

"Serverless IaC and local testing" -- SAM

"Git-based AWS source repository" -- CodeCommit

"Packaging build output" -- CodeBuild artifacts

"Adding manual approval to pipeline" -- CodePipeline manual approval stage

Understand the precise difference between buildspec.yml (how to build) and appspec.yml (how to deploy)

Back to blog list