Pipeline Design for Microservices · CI/CD for Microservices in Microservices | Microservices with Spring Cloud

Independent Pipelines

The main promise of microservices is independent deployment: the payments team can release on Tuesday without waiting for the catalogue team. That only works if every service has its own pipeline that builds, tests and deploys just that service.

git push (order-service/**)
      |
      v
 +---------+   +-------------------+   +-------------+   +-----------+   +--------------+
 |  Build  |-->| Test: unit,       |-->| Docker image|-->| Deploy to |-->| Deploy to    |
 | mvn     |   | integration       |   | push :sha   |   | staging + |   | production   |
 | verify  |   | (Testcontainers), |   | + scan      |   | smoke test|   | (approval,   |
 +---------+   | contract tests    |   +-------------+   +-----------+   |  canary)     |
               +-------------------+                                     +--------------+
   CI = Continuous Integration: every change is built and tested
   CD = Continuous Delivery (one click to prod) / Deployment (automatic to prod)

Monorepo or Polyrepo?

	Monorepo (all services in one Git repo)	Polyrepo (one repo per service)
Pipelines	One workflow per service, triggered by `paths:` filters	One workflow per repo
Shared code	Easy: a shared module (but beware coupling)	Published as versioned libraries
Cross-service change	One pull request	Several PRs, released in order
Access control	Coarse	Per team
Used by	Google, Uber, many startups	Amazon, Netflix, many enterprises

Note: Both work. What matters is that a change to order-service builds and deploys only order-service.

What to Test Where

Test type	Checks	Tool	Runs in
Unit	Business logic in one class	JUnit 5, Mockito	Every push
Integration	Service + real database/Kafka	@SpringBootTest + Testcontainers	Every push
Contract	My API still matches what consumers expect	Spring Cloud Contract, Pact	Every push, both sides
Smoke / end-to-end	Key flows work in a real environment	REST Assured, Postman/Newman	After deploy to staging

Tip: Avoid one giant end-to-end suite that needs all 15 services: it is slow and flaky, and it couples releases again. Contract tests give most of the safety at a fraction of the cost.