CI/CD Pipeline for Microservices, Stage by Stage

Splitting an application into services should make releases smaller and safer. Without a good delivery process, it does the opposite: many repositories, many deployments and many chances for a change in one service to break another. A CI/CD pipeline is the automated path from a code change to a running release. For microservices it needs to build and test each service independently, check that services still work together and deploy in a way that can be rolled back quickly. This guide explains the stages a CI/CD pipeline should include, how to adapt it for multiple services and the habits that keep it fast and trustworthy.

Continuous integration first

Continuous integration is the foundation. Martin Fowler's article on the practice lists habits such as keeping everything in a version-controlled mainline, automating the build, making the build self-testing, having everyone push commits to the mainline every day, triggering a build on every push, fixing broken builds immediately and keeping the build fast (Martin Fowler: Continuous Integration).

These habits matter more than any particular tool. A pipeline that runs on every change but is often broken, or so slow that people avoid it, does not deliver the benefit.

The stages of a CI/CD pipeline

A typical pipeline for one service runs these stages in order:

1. Build: compile the code or install dependencies and produce a versioned artifact, such as a container image.
2. Unit tests: fast tests of the service's own logic.
3. Static checks: linting, dependency vulnerability scanning and configuration checks.
4. Integration and contract tests: confirm the service works with its database and with the APIs it uses and provides.
5. Deploy to a test environment: run the artifact in an environment that resembles production.
6. Acceptance or smoke tests: check key journeys against the deployed service.
7. Deploy to production: release, ideally with a strategy that limits impact if something goes wrong.

Fowler's list also includes testing in a clone of the production environment and automating deployment, which correspond to the last stages here.

Build once, promote the same artifact

Build the artifact once and promote that exact artifact through each environment. Rebuilding for production risks shipping something different from what was tested. Tag artifacts with the commit they came from so that anyone can trace a running version back to its source.

Configuration that differs between environments, such as database addresses and credentials, should be supplied at deploy time rather than built into the artifact.

Adapting the pipeline for microservices

Microservices add specific challenges:

• Independent pipelines: each service should build, test and deploy on its own, so a change to one does not require releasing all of them.
• Shared templates: keep a common pipeline definition that services reuse, so that improvements reach every service without copying.
• Contract testing: check that changes to one service's API do not break its consumers before deploying.
• Dependency awareness: know which services depend on which, so you can decide what to test when a shared component changes.
• Environment management: decide whether each change gets its own test environment or shares one, and how test data is prepared.

Deployment strategies that limit risk

The final stage should make rollback easy. Common strategies include rolling updates, where instances are replaced gradually; blue-green deployments, where traffic switches between two environments; and canary releases, where a small share of traffic goes to the new version first. On Kubernetes, rolling updates and readiness checks are the usual starting point; our guide to Kubernetes zero downtime deployment covers the settings involved.

Whatever strategy you use, automate the rollback path and test it, not just the release path.

Treat infrastructure and pipeline config as code

The pipeline definition, deployment manifests and the infrastructure they run on should all live in version control and go through review. That way, a change to how a service is deployed is as visible and reversible as a change to its code. Our guide to infrastructure as code explains how to manage cloud resources this way.

Worked example: a pipeline for one service

The table below is a hypothetical pipeline for an order service, using a hosted CI system such as GitHub Actions, which the GitHub documentation describes as covering continuous integration and continuous deployment workflows (GitHub Actions documentation).

StageTriggerWhat runsBlocks the next stage if it fails?BuildEvery pushInstall dependencies, build image tagged with commitYesUnit testsEvery pushService unit testsYesStatic checksEvery pushLinting and dependency scanYes, for high-severity findingsContract testsEvery pushProvider checks against consumer expectationsYesDeploy to stagingMerge to mainSame image deployed to stagingYesSmoke testsAfter staging deployCreate, read and cancel an orderYesDeploy to productionManual approvalCanary release, then full rolloutRollback on failed health checks

Every stage either passes or stops the pipeline. Stages that only warn tend to be ignored over time.

Include database changes

Services that own databases need schema changes to move through the same pipeline as code. Write migrations as versioned files, run them automatically as part of deployment and design them so that the old and new versions of the service can both run against the database during a rollout. That usually means adding columns before using them and removing old ones only after no running version needs them. Treating migrations as an afterthought is one of the most common reasons a rollback fails, because the code goes back but the database does not.

Decide who owns the pipeline

Shared pipeline templates need an owner, usually a platform or DevOps function, who maintains them, reviews changes and helps teams adopt improvements. Each service team still owns its own tests and deployment settings. Without clear ownership, templates drift, fixes are copied inconsistently and nobody notices when a stage stops doing anything useful.

Keep the pipeline fast

Slow pipelines lead people to batch changes, skip tests or bypass the process. Keep feedback quick by running fast tests first, running independent stages in parallel, caching dependencies and moving slow suites to later stages or scheduled runs. Track pipeline duration and failure rate as metrics in their own right.

Secrets and permissions

Pipelines hold powerful credentials: access to registries, clusters and cloud accounts. Store secrets in the CI system's secret store or a dedicated secrets manager, give each pipeline only the permissions it needs and restrict who can change production deployment steps. Review these permissions when people change roles.

Frequently Asked Questions

What is a CI/CD pipeline?

It is an automated process that builds, tests and deploys code changes, so each change moves from commit to release through the same checked steps.

Should each microservice have its own pipeline?

Yes, in most cases. Independent pipelines let services release separately. Shared templates keep them consistent without duplicating work.

What is the difference between continuous delivery and continuous deployment?

In continuous delivery, every change is ready to release but a person approves production deployment. In continuous deployment, changes that pass all checks go to production automatically.

How do I stop one service's change breaking another?

Use contract tests between services, deploy with strategies that limit exposure, such as canary releases, and keep rollback automated and tested.

Ship changes safely and often

We design delivery pipelines, deployment strategies and infrastructure as code for teams running multiple services. See our custom app development services, or talk to us about your CI/CD pipeline.

About the Author

Manav Sharma is the founder of Insyrge and a CRM solutions architect. He works across Zoho, Salesforce, HubSpot, Odoo and more, designing the CRM setups, integrations and automations that keep sales and operations teams working from the same data.