Why this matters
- This topic directly affects how reliably BookStore reaches production — the devops toolchain chains git, build, ci, registry, orchestration, and observability so bookstore artefacts flow without manual handoffs..
- Interviewers connect hands-on commands and manifests to real delivery stories, not buzzwords.
- Later modules assume you can explain both the why and the concrete file or command involved.
- Platform maturity shows up when teams automate this instead of relying on tribal knowledge.
SourceGit push / PR
Buildmvn package
TestUnit + integration
PackageDocker image
PublishPush to registry
DeployStaging → Prod
Tool categories
BookStore connects GitHub, Maven, Docker, a CI platform, GHCR, Kubernetes, Prometheus, and Terraform modules. Each tool owns one lifecycle concern.
Key ideas
- Source control — Git history and PR workflow
- Build — Maven produces tested JARs
- CI/CD — pipelines orchestrate verify, image, deploy
- Observability — metrics/logs/traces for the catalog API
Artefact flow
A merge to main triggers mvn verify, builds ghcr.io/bookstore/api:sha, deploys to staging, runs smoke tests, and exposes metrics to Grafana.
Key ideas
- Registry — immutable image storage
- Orchestration — Kubernetes schedules pods
- IaC — Terraform provisions clusters and DNS
- Secrets — Vault or cloud secret managers feed CI
Choosing tools deliberately
Adopt tools that integrate with adjacent stages. BookStore rejected overlapping CI and custom shell deploy scripts when GitHub Actions plus ArgoCD covered the same ground with less toil.
Key ideas
- Integration — fewer handoffs between systems
- Skill fit — match team expertise
- Cost — agent minutes and registry egress
- Exit plan — avoid proprietary lock-in without reason
git push → GitHub Actions → mvn verify → docker build
→ push ghcr.io/bookstore/api:sha → deploy staging → prometheus scrape
Quick recall
Everything you need if you only revisit this box.
- BookStore uses devops toolchain map as a standard delivery practice.
- Prefer automation and versioned config over manual server changes.
- Staging proves changes before customer-facing promotion.
- Observability confirms success — do not rely on silence alone.
- Rollback plans must be tested, not invented during an outage.
- Security and least privilege apply to every pipeline and cluster role.
Test yourself
Answer these before moving on — recall is what makes it stick.