Promotion by retag, not rebuild
The thing that runs in prod must be byte-identical to what was smoke-tested in QA. Rebuilding on promotion re-introduces supply-chain risk for no benefit.
DevOps · CI/CD · Kubernetes · Self-directed
A full Jenkins pipeline that takes the Spring Boot PetClinic microservices app from a git push to a running deployment on AWS EKS, with a dev → QA → prod promotion flow, ECR image management, Selenium smoke tests, Rancher cluster operations, and Prometheus + Grafana observability.
The Spring PetClinic reference app is split into a handful of services (customers, vets, visits, api-gateway, admin, config, discovery). Each one has its own Dockerfile and its own Jenkins pipeline stage — the unit of delivery is a service, not the whole app.
dev, qa, prod — each an EKS namespace with its own config and secrets.:<git-sha> tag, and promotion is a retag, not a rebuild.
The Jenkinsfile is declarative, parameterized on target environment,
and runs each stage only for services whose code changed in the
current commit. That way a one-line fix to customers-service
doesn't rebuild every image in the repo.
docker build per service, tagged with the git SHA.petclinic-dev namespace on EKS.petclinic-qa manifests.petclinic-prod.Everything outside the app itself runs on AWS — the EKS cluster, the ECR registries, the Jenkins controller + agents, Nexus, and the monitoring stack. Cluster is 3 worker nodes by default; Rancher overlays multi-cluster management.
# Namespaces — one per environment, with RBAC + network policies
kubectl create namespace petclinic-dev
kubectl create namespace petclinic-qa
kubectl create namespace petclinic-prod
# ECR login for Jenkins agent (via IRSA / instance role in the real pipeline)
aws ecr get-login-password --region us-east-1 \
| docker login --username AWS --password-stdin \
<account>.dkr.ecr.us-east-1.amazonaws.com
# Rollout to the target namespace
kubectl -n petclinic-$ENV apply -f k8s/
kubectl -n petclinic-$ENV rollout status deploy/customers-service
Each Spring Boot service exposes Micrometer metrics at /actuator/prometheus.
Prometheus scrapes via the Kubernetes service-discovery SD config;
Grafana dashboards show JVM health, HTTP latency percentiles, and
per-pod resource usage side by side with the rollout timeline.
The thing that runs in prod must be byte-identical to what was smoke-tested in QA. Rebuilding on promotion re-introduces supply-chain risk for no benefit.
Monolithic pipelines optimize for the case where you change everything at once. In reality you almost never do. Per-service pipelines cut feedback time dramatically.
When multiple clusters and multiple namespaces enter the picture, Rancher's RBAC and context switching are worth the overhead of running the control plane.
Unit tests gate the build; Selenium against the real deployed URL gates promotion. Different questions, different tools.