Your Deployment Pipeline Is Not Your SDLC

A team ships to production twenty times a week. Every merge triggers a build. Tests run automatically. Deployments are one click. The pipeline is green. And every sprint, the same things happen: features arrive half-finished, acceptance criteria get written after the code, bugs found in review get pushed to the next sprint because "we'll fix it then," and nobody can say with confidence what will actually ship by Friday.

The pipeline is working. The process around it is not.

This is a common pattern. Teams invest heavily in CI/CD tooling because it's concrete, measurable, and satisfying to set up. The dashboard shows green ticks. Deployment frequency goes up. Mean time to recovery drops. All the DORA metrics trend in the right direction. Meanwhile, the actual engineering process — the part where people decide what to build, agree on what "done" means, and verify that the right thing got built — stays broken.

What CI/CD Actually Solves

CI/CD solves a specific, mechanical problem: getting code from a developer's machine to a running environment with minimal manual intervention. It catches compilation errors. It runs automated tests. It packages artifacts and deploys them. This is valuable. Teams that deploy manually, with runbooks and SSH sessions and a single person who knows the process, are objectively worse off than teams with automated pipelines.

But CI/CD solves the how of delivery. It does not solve the what or the whether. It doesn't tell you whether the feature you just deployed actually solves the problem it was meant to solve. It doesn't tell you whether the acceptance criteria were correct in the first place. It doesn't catch the case where a feature passes every automated test but doesn't match what the product owner described in the standup three weeks ago.

A pipeline is a delivery mechanism. Confusing it with an engineering process is like confusing a postal service with the letters it carries.

The Process Debt You Can't See in GitHub Actions

The problems that slow teams down and produce unreliable software aren't visible in CI dashboards. They show up in the gaps between pipeline stages.

• No acceptance criteria before development starts. A ticket has a title and a vague description. The developer interprets it, builds something, and discovers in review that it doesn't match what was intended. The rework cycle starts. Sometimes it takes two or three passes.
• "Definition of done" that means "tests pass." Code compiles, unit tests run, the PR gets approved. But nobody verified the feature works end-to-end from a user's perspective. Nobody checked the edge cases. Nobody tested what happens when the network is slow or the data is messy.
• QA as a phase instead of a practice. Testing happens at the end, in a separate sprint, by a separate team. By the time bugs are found, the developer has moved on to something else. Context switching costs are real, and they compound.
• Sprint commitments based on gut feel. Velocity is tracked but not used for planning. Estimates are optimistic by default. Work carries over sprint after sprint, and the team normalises the carryover instead of addressing why it happens.

None of these show up as a red build. The pipeline stays green while the team's actual throughput — useful features delivered to users — stays flat or declines.

What a Working SDLC Looks Like

A functioning software development lifecycle isn't about ceremonies or frameworks. It's about a handful of practices that, done consistently, make the difference between a team that ships reliably and a team that ships frequently but unpredictably.

Acceptance criteria are written before code. Not during development, not during review. Before. The criteria describe the specific behaviour the feature must exhibit to be considered complete. They're written by whoever understands the requirement best — product owner, lead developer, designer — and they're the contract that the developer builds against. If the criteria are wrong, you find out before you've written 400 lines of code, not after.

Code review is an architecture conversation, not typo patrol. Reviewers check whether the approach makes sense, whether the code will be maintainable in six months, and whether it handles the cases the acceptance criteria describe. Style nits are handled by linters. If your review process is mostly about formatting and naming, you're wasting the most expensive part of your development cycle on work that a machine can do better.

QA is embedded in development. Testing isn't a handoff. Developers test their own work against the acceptance criteria before opening a PR. If the team has dedicated QA engineers, they work alongside developers during the sprint, not after it. Bugs found during development are cheap. Bugs found in production are expensive. Bugs found in a separate QA sprint are somewhere in between, but the context-switching cost makes them feel more expensive than they should.

Retrospective findings actually change behaviour. If your retros produce the same action items every month — "we need better requirements," "we should write more tests," "we need to stop carrying work over" — the retro itself isn't the problem. The problem is that findings don't translate into specific, tracked changes. An action item without an owner and a deadline is a wish.

A green pipeline with a broken process is a fast car with no steering wheel. You'll get somewhere. It just won't be where you intended.

The Diagnostic

If you want a quick read on whether your engineering process is actually working — not your tooling, your process — answer these five questions honestly:

• How often do features get rejected or significantly reworked in code review? If it's more than occasional, your upfront requirements process isn't working. Review should catch design problems now and then, not routinely.
• How often do bugs come back after being marked resolved? Recurring bugs mean the fix addressed a symptom, not the cause. That's a testing and review gap.
• How predictable are your sprint outcomes? If you regularly commit to ten items and ship six, the problem isn't estimation precision — it's that the team is planning against hope instead of capacity.
• Can you explain, without checking the ticket, what the last three features you shipped were supposed to do for users? If the team can't articulate the user value of what they built, the requirements weren't clear enough to build against in the first place.
• When did your process last change because of something you learned in a retrospective? If the answer is "not recently," your retros are theatre.

No pipeline dashboard will surface these. They require a different kind of visibility — the kind that comes from looking at how decisions get made, not just how code gets deployed.

Fixing the Process, Not Just the Pipeline

Engineering process improvement is less glamorous than setting up a new CI/CD platform. It doesn't produce screenshots for a blog post. It doesn't have a green tick that appears when it's done. It's ongoing, messy, and organisational. It requires buy-in from the people doing the work, and it requires someone to keep pushing when the team backslides — which it will, because process discipline is harder than tooling.

But it's the work that actually moves the needle. Teams with clear requirements, strong review practices, and honest sprint planning ship fewer bugs, hit their commitments more often, and waste less time on rework. The pipeline is the easy part. Getting the process right is what separates teams that ship fast from teams that ship well.