Engineering case study

EKS · GitHub Actions · Argo CD

Petclinic: an EKS platform with GitOps delivery

An AWS platform that builds selected Spring services, publishes immutable images, updates Git-managed Helm values, and lets Argo CD reconcile eight services across development and production environments.

TerraformEKSHelmArgo CDGitHub ActionsPrometheus

Platform repository Application repository No permanent live demo

deployable services

environment roots

platform workflows

release quality gates

The problem

What needed to be solved

A distributed Spring application has ordering, identity, secrets, networking, database, and observability requirements that cannot be solved by merely pushing eight containers to a cluster. The release path also needed to rebuild only what changed and preserve a reviewable deployment history.

My role

What I owned

I built the infrastructure and GitOps platform around the Spring Petclinic microservices fork: Terraform modules and environment roots, AWS identity and secrets integration, reusable Helm charts, Argo CD applications, and the cross-repository CI/CD handoff. The original Spring Petclinic application is an open-source upstream project; my work here is the platform and delivery engineering.

Architecture

How the system fits together

Application CI

Maven, Docker, Trivy

Amazon ECR

Commit-SHA image tags

GitOps update

Helm values committed to Git

Argo CD

Sync, prune, and health gates

Amazon EKS

Eight Spring services

Platform services

RDS, secrets, ingress, observability

Application CI builds changed services and publishes images to ECR. A repository dispatch updates Git-managed image tags, then Argo CD reconciles Helm releases on EKS and waits for service health.

Key decisions

Engineering choices and trade-offs

Short-lived AWS access through OIDC

GitHub Actions assumes a bootstrap-managed IAM role instead of storing long-lived AWS access keys in repository secrets.

Selective builds with immutable image identity

CI detects changed service directories, runs a matrix only for those services, scans images, and tags successful builds with the commit SHA.

Git is the deployment source of truth

A dispatch updates service-specific Helm values and commits the new image tag. Argo CD owns reconciliation instead of CI directly mutating workloads.

Platform capabilities are installed with the cluster

Terraform provisions EKS, RDS, ECR, ingress and DNS, External Secrets, Argo CD, Prometheus, Grafana, Loki, Fluent Bit, Zipkin, and CloudWatch log groups.

CI/CD snapshot

A successful app build becomes a traceable GitOps change

The application pipeline dispatches only the changed services and their commit SHA. The platform workflow writes those immutable tags into Helm values before triggering Argo CD.

Inspect the source file

.github/workflows/update-image-tags.yaml

on:
  repository_dispatch:
    types: [app-image-built]

- name: Update image tags in helm-values
  run: |
    IMAGE_TAG="${{ github.event.client_payload.sha }}"
    SERVICES="${{ github.event.client_payload.services }}"

    for SERVICE in ${SERVICES}; do
      sed -i "s|tag: .*|  tag: "${IMAGE_TAG}"|" \
        "helm-values/${SERVICE}.yaml"
    done

Measurable outcome

What the implementation demonstrates

The release path handles eight services while building only service directories changed by a commit.
Every deployed image is traceable to a short Git commit SHA recorded in the GitOps repository.
A CRITICAL-severity Trivy gate blocks unsafe image publication; Argo CD then waits for selected applications to report both Synced and Healthy.
One generic Helm chart plus service-specific values replaces duplicated workload templates across development and production.