Self-directed · Spring PetClinic
Enterprise Microservices CI/CD Pipeline
End-to-end Jenkins pipeline deploying a Java Spring microservices application to AWS EKS, with promotion across three environments.
- Discipline
- CI/CD · Containers
- Services
- Spring microservices
- Target
- AWS EKS
- Jenkins
- AWS EKS
- ECR
- Rancher
- Nexus
- Maven
- Docker
- Selenium
- Prometheus
- Grafana
Sheet B
Specification
What it is
Spring PetClinic decomposed into microservices, with a Jenkins pipeline that takes a commit through build, test, image publication, and rollout to AWS EKS.
The application is a well-known reference implementation, and that is the point — it removes application novelty from the exercise so the delivery mechanics are the actual subject.
The pipeline
Maven builds each service and runs its unit tests. Images are tagged and pushed to AWS ECR. Deployment targets an EKS cluster managed through Rancher, with Selenium exercising the running application before a build is considered promotable.
Promotion runs across three environments on a multi-branch model, so a change is validated in a real deployment before it is eligible for the next stage (see note 1).
Observability
Prometheus scrapes the cluster and the services; Grafana carries the dashboards. The pipeline can report a green build, but a green build that produces a service failing its readiness probe is not a successful delivery — having the metrics in the same place as the rollout closes that gap.
Sheet C
Notes
2 items
Sheet D
Revisions
What I would change
- 01Move the pipeline to GitHub Actions. Jenkins was the right vehicle for learning the mechanics end to end, but a self-hosted controller is infrastructure to maintain for a project this size.
- 02Replace Nexus with ECR alone. Running two artefact stores taught the difference between them, and then stopped earning its keep.