CI/CD is more than just automation; it’s about making life easier for developers. When I set out to build a pipeline for my Spring Boot application, I wanted something that could handle everything—from build to deployment—without manual intervention. After some trial and error, I ended up with a setup that integrates GitHub Actions, AWS ECR, S3, and Helm.

This blog isn’t a step-by-step tutorial. Instead, it’s a breakdown of why I structured my pipeline the way I did, what challenges I faced, and how I solved them.

The Goal: A Clean & Modular CI/CD Pipeline

I wanted a system that:

• Built the application using Maven.
• Scanned for vulnerabilities.
• Created & pushed Docker images to AWS ECR.
• Deployed the app to AWS EKS using Helm.

Instead of cramming everything into one file, I split it into modular GitHub Actions workflows:

• Build Workflow → Handles Maven builds and uploads artifacts to AWS.
• Dockerization Workflow → Builds & pushes Docker images.
• Security & Deployment Workflow → Scans for vulnerabilities and, if clean, deploys the app to EKS.
• Code Quality Workflow → Runs SonarQube for code quality analysis.

This structure makes debugging easier and keeps the pipeline maintainable.

Breaking Down the Key Workflows

Building the Application

Compiling the code is straightforward, but ensuring the artifact is available for the next steps is crucial. I use Maven to build the project and then upload the artifact to AWS ECR or S3. This ensures that subsequent workflows don’t have to rebuild everything from scratch.

SonarQube for Code Quality

Code reviews only catch so much. SonarQube helps by scanning for bugs and code smells before deployment. This step prevents bad code from sneaking into production and keeps technical debt under control.

Dockerizing the App

Initially, I bundled the image-building process within the build workflow. However, separating it made things cleaner and more modular. The process involves pulling the built artifact, creating a Docker image, and pushing it to AWS ECR.

Security Scan & Deployment

This workflow serves two purposes:

1. Runs a security scan to catch vulnerabilities early.
2. Deploys the app to AWS EKS if no critical issues are found.

Trivy was a lifesaver here. It flagged a few vulnerabilities initially, but after refining my dependencies and base images, the scans became much cleaner. Automating this check ensures only secure images make it to production.

Challenges & How I Solved Them

1. Managing Helm Charts

I originally had one massive Helm chart for everything, which got messy fast. Splitting it into separate charts per service made updates easier and more maintainable.

2. Speeding Up GitHub Actions

Maven builds can be slow, and every second counts in CI/CD. Caching dependencies helped reduce build times significantly. It was a small change, but it made a noticeable difference in execution speed.

3. Handling Trivy False Positives

Some low-risk vulnerabilities weren’t actually a problem, but Trivy still flagged them. Fine-tuning the scan severity levels helped filter out unnecessary noise while keeping the important security issues in check.

Final Thoughts

This CI/CD setup has been a game-changer for me. It automates everything—build, test, security, containerization, and deployment—without unnecessary manual work. It’s modular, easy to maintain, and scalable.

If you’re setting up a pipeline for your own Spring Boot app, consider breaking it into separate workflows like this. It’ll save you a ton of headaches in the long run.