Automated pipelines that test every change and ship it, replacing slow, error-prone manual steps.
Why it exists
Manually testing and deploying every change is slow, inconsistent, and easy to get wrong under pressure, because people forget steps. CI/CD exists to automate the build, test, and deploy pipeline, so every change is checked the same way and shipping becomes a push of a button rather than a ritual.
How it actually works
CI (continuous integration) automatically runs the test suite on every proposed change, catching breakage before it merges. CD (continuous delivery/deployment) automatically ships approved changes to staging or production once they pass.
Together they turn shipping into a reliable, repeatable pipeline: write code, it's tested automatically, it's deployed automatically. Faster releases with fewer human mistakes.
A senior PM walks you through it
A junior PM, stuck
I asked the dev whether the discount feature ships today and he said "pipeline is red" and sent me the CI file plus a failing job. I cannot map any of that to the one thing I need to tell my lead, which is when it actually goes out. I do not want to guess a date and be wrong in front of the room.
Red means one automated stage failed and stopped the line before anything shipped, so "when does it ship" has a readable answer sitting in these two views. Below is the .gitlab-ci.yml that defines the stages, next to last night's run showing exactly where it stopped. Five minutes and you can tell your lead the real gate, not a guess.
TiffinBox .gitlab-ci.yml and last night's failed run
11FAIL checkout.test.ts: expected order total 649, received 1
Click a step to see the lines it points at.
Mistakes I've seen
Reading "pipeline is red" as a vague setback and reporting "it's delayed" upward. Red names an exact stage; open the run, find the first failed one, and report that instead of a mood.
Promising a ship date off a green pipeline that has a manual production gate. Green clears the tests; a person still has to approve the deploy-prod step, so confirm who clicks it before you commit to a time.
Treating skipped stages as extra failures. A failed test stage skips everything after it; there is one problem to fix, not one per skipped stage.
Asking the dev to "just push it out anyway" past a red test. The failing checkout test is the discount feature charging 1 taka instead of 649; shipping past it ships the bug.
Tell your lead: "The pipeline is red because a checkout test is failing in the test stage, the discount code is pricing a Kacchi order at 1 taka instead of 649, so nothing has deployed. It ships once that test passes and someone approves the manual production step, not before." You read a CI file and a run, found the first failed stage, and turned "it's red" into a specific blocker and gate.
Where a PM meets this
Good CI/CD means teams ship small changes often and safely; it's a major factor in how quickly your roadmap can actually move.
"The pipeline is red" means automated tests are failing and shipping is blocked until fixed, useful to recognize.
Hear it in a meeting
"Pipeline's green, it'll auto-deploy to staging in a few minutes."