Introduction
When our organization decided to migrate its infrastructure to AWS, one thing became clear:
“We want everything inside AWS — no more managing a patchwork of tools.”
At the time, our CI/CD pipeline was built using Bitbucket Pipelines, with scattered usage of:
Bitbucket Secrets
Custom shell scripts
DockerHub for container images
It worked — but it was fragile, fragmented, and difficult to scale securely.
As part of the broader AWS-first strategy, I was tasked with moving our entire build, test, and deploy lifecycle into the AWS ecosystem.
This article walks through:
What we built using AWS CodeBuild
SonarQube integration for static analysis
JUnit test reporting for visibility
buildspec.yml explained section-by-section
IAM roles needed
Challenges we overcame
Key outcomes we achieved
Why We Moved to AWS CodeBuild
Prime reasons for the migration
This wasn’t just about replacing Bitbucket — it was about building a resilient, secure, and scalable pipeline inside AWS.
Our AWS-Native CI/CD Architecture
CodeBuild Project Architecture
SonarQube Integration — Continuous Code Quality
One of our most important additions was integrating SonarQube scanning into every build.
Why it matters:
Detects bugs, vulnerabilities, and code smells early
Enforces coding standards and quality gates
Helps developers write better, cleaner code every day
How I did it:
Installed the scanner tool dynamically
Pulled tokens securely from AWS Secrets Manager
Triggered scans before and after builds
Integrated dashboards for team visibility
This made code quality a daily practice, not an afterthought.
JUnit Test Reporting — Real-Time Feedback
Another win from this migration was getting test feedback directly in the AWS CodeBuild console through JUnit reports.
What Changed:
Configured test runners (like dotnet test) to emit JUnit-compatible .trx reports
Declared test reports in the buildspec.yml
These reports now show pass/fail metrics directly in the AWS UI, and can be passed to CodePipeline stages or Slack alerts.
Why It Matters:
🧩 Breaking Down the buildspec.yml — Phase by Phase
The buildspec.yml is the backbone of AWS CodeBuild. Here’s a breakdown of each section we implemented — what it does, and why it matters.
🔧 Version Declaration
Specifies the buildspec syntax version. 0.2 enables advanced features like reports, runtime versions, and more structured phase control.
🔍 Install Phase
🧠 Purpose:
Install essential tools like jq for parsing secrets and dotnet-sonarscanner for code analysis
Add the tools to the PATH so they’re available in all phases.
⚙️ Pre-Build Phase
🧠 Purpose:
Clean any residual build files
Ensure submodules are available for use
Login to Amazon ECR
Securely fetch credentials and secrets dynamically.
🏗️ Build Phase
🧠 Purpose:
Run code quality checks (SonarQube).
Build and test the application.
Output test results in JUnit-compatible format.
Build Docker image and tag it.
📦 Post-Build Phase
🧠 Purpose:
Push Docker image to ECR.
Clean up local image cache to reduce space usage.
📊 Artifacts and Test Reports
🧠 Purpose:
Preserve test artifacts and reports.
Allow AWS CodeBuild to display test results graphically in the AWS console.
Enable integration with other tools like AWS CodePipeline or notifications.
🔐 IAM Roles and Policies
To make this work securely, CodeBuild role was granted permission to:
Retrieve secrets from AWS Secrets Manager.
Authenticate and push to Amazon ECR.
Stream logs to CloudWatch.
Generate and publish test reports.
IAM trust was granted to codebuild.amazonaws.com, and we scoped all policies with the least-privilege principle.
✅ Objectives Achieved
This wasn’t just a migration — it was a transformation. Here’s what we unlocked:
✅ Final Thoughts
This migration wasn’t just about tools — it was about standardizing quality, scaling securely, and moving fast without breaking things.
With CodeBuild, SonarQube, Secrets Manager, and JUnit reporting, we now have:
Cleaner builds.
Higher quality code.
Secure pipelines.
Unified AWS-native DevOps.
This is what modern CI/CD looks like — and we’re just getting started.
👋 Let’s Connect
📢 Follow me for part 2: Migrating from AWS CodeBuild to AWS CodePipeline
🛠️ Reach out if you’re migrating to AWS and need a working model
Top comments (0)