Two Practices for Building and Deploying Microservices Independently

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Create a separate release pipeline for each microservice and trigger them in sequence using pipeline completion triggers.

  Why it's wrong here

  Separate release pipelines per microservice with pipeline completion triggers create implicit, decentralized orchestration rather than a single auditable deployment plan. This approach makes cross-service ordering, environment approval gates, and coordinated rollbacks difficult to manage, and multiplies the number of pipelines, service connections, variables, and permissions that operators must maintain.

• ✗

  Create a single build pipeline that produces all container images, then a release pipeline that deploys the single artifact.

  Why it's wrong here

  A single build pipeline that produces all container images couples the build lifecycle of every microservice, so any one code change unnecessarily triggers builds and potential deployments for all services. It also yields a single monolithic deployable artifact, erasing per-microservice versioning and granular release, which increases the blast radius and defeats the independent scaling and deployment benefits of a microservices architecture.

• ✓

  Create a single release pipeline that consumes multiple build artifacts (one per microservice) and uses a Helm chart per microservice, deploying them in stages.

  Why this is correct

  A single release pipeline consuming multiple build artifacts, one per microservice, preserves independent artifact versioning while centralizing deployment coordination in one auditable process. Using a Helm chart per microservice allows each service to be templated and configured independently, while shared release stages, approval gates, and rollback steps can orchestrate the full deployment consistently across environments.

• ✗

  Create a single multi-stage YAML pipeline that builds and deploys all microservices together.

  Why it's wrong here

  A single multi-stage YAML pipeline that builds and deploys all microservices together tightly couples build and release phases, preventing build artifacts from being reused or promoted independently across environments. It also complicates applying different approval gates per service and forces a full rebuild of the entire application when only one microservice changes, which undermines modular deployment and increases CI/CD cycle time.

Go deeper

Related to this question