How to Build a CI/CD Pipeline: A Complete Guide

Frequently Asked Questions

01.What are the main stages of a CI/CD pipeline?

A typical pipeline runs checkout, dependency install, lint and type checks, unit tests, a single build that produces a versioned artifact, integration tests, dependency and image scans, and then deployment to staging and production. Continuous delivery keeps a human approval before production; continuous deployment ships every change that passes.

02.Should a CI/CD pipeline use OIDC instead of stored cloud keys?

Yes, where the cloud provider supports it. With OIDC the CI platform presents a signed identity token and receives a short-lived credential valid for a single job, so there is no long-lived key to leak from settings or logs. GitGuardian reported in March 2025 that seven in ten secrets leaked in 2022 were still active; OIDC removes long-lived cloud keys from the pipeline, so CI settings and logs stop being one source of that exposure.

03.Does splitting tests into parallel jobs increase CI costs?

In our worked example, the minutes added cost far less than the waiting removed is worth: eight parallel jobs cut a wait of about thirteen minutes to under three while billed minutes rose from fourteen to twenty-four, because GitHub rounds each job up to a whole minute and every job repeats its setup. Going on to twenty-four jobs doubled billed minutes again to save one more minute.

04.Which deployment strategy should a first CI/CD pipeline use?

A rolling update is the usual starting point, because Kubernetes Deployments use it by default and it needs no second environment. Add canary releases once error rate and latency metrics are trusted enough to stop a release automatically, and use blue-green where a release needs a clean cutover between two full stacks.