What Actually Happens Between Your Pull Request and Production

The short answer: what a CI/CD pipeline actually does

A CI/CD pipeline is the automated path your change takes from a pull request to production: it builds your code into an artifact, tests it in layers, deploys it gradually, and watches what happens next. Every stage exists to answer one question, "is there a reason not to let this go further?", and every stage is there because at some point somebody shipped something that broke.

You open a pull request. Some checks appear. A colleague leaves comments. Eventually it merges, and some time later your change is live. Most engineers learn this as a sequence of buttons rather than as a system. That works until something breaks in the middle, and then you are staring at a red pipeline with no idea which stage failed or why it matters.

I am a Lead Full Stack Engineer, and reading a failed pipeline quickly is one of the most underrated skills I see in juniors. This post walks through the whole thing, stage by stage, what each one protects you from, the difference between rolling, blue-green and canary releases, and how to tell in ten seconds what a red X is telling you.

CI/CD pipeline stage one: the change itself

You branch, commit, push and open a pull request. The parts worth caring about here are unglamorous:

• Keep branches short-lived. A branch that lives for three weeks turns into a merge conflict you will spend a day on. Merging small changes often is the whole idea behind continuous integration.
• Write commit messages that say why. The diff already says what.
• Keep pull requests small. A few hundred lines at most, ideally far fewer.

That last point matters more than anything else on this list. A reviewer given 60 lines finds real problems. A reviewer given 2,000 lines skims and approves. Google's large study of its own code review practice, Modern Code Review: A Case Study at Google, found that most changes there are small, with a median of around 24 lines modified, and that small changes get feedback much faster. Google's engineering practices guide is public and explains how they review, including why small changes are the default.

If Git itself still feels like magic, read Git: the model behind the commands and my answer on how to learn Git and GitHub properly.

Stage two: build

The moment you push, something notices and starts working. In most student projects and many companies, that is GitHub Actions, though GitLab CI, Jenkins and others do the same job.

The build turns your source into an artifact: usually a container image, sometimes a package or binary. The important property is that this artifact is the thing that goes to production. Not a rebuild later, not the same code compiled again on a different machine. The exact bytes that were tested are the exact bytes that ship.

That is why good builds pin their dependency versions and base images. If your build pulls latest of anything, two builds of the same commit can produce different software, and every test result you have is about a thing that no longer exists. Lock files, pinned image digests and reproducible builds are how you avoid that. The SLSA framework takes this further for supply chain security, but pinning is the part every team needs.

The artifact goes into a registry so that staging and production both pull the same one. Docker's getting started guide is the easiest way to understand images and registries if you have not used them.

Stage three: test

This stage runs in layers, fastest first, because feedback speed matters:

• Linting and formatting. Trivial, instant, and it removes an entire category of pointless review comments.
• Unit tests. Does each piece behave as expected in isolation? Fast, and they must stay fast, because a slow unit suite is one people stop running locally.
• Integration tests. Does it still work when the pieces are connected to a real database? Slower, fewer of them, and they catch what unit tests structurally cannot.
• Security scanning. Known vulnerable dependencies, committed secrets, obvious injection patterns. Cheap to run and occasionally saves you from something serious. Gitleaks and GitHub's code security features are free starting points.
• Human review. Another engineer reads the change. This is not redundant with automation. It catches a different class of problem: wrong approach, missing case, code that works but nobody will be able to maintain.

If any layer fails, the change stops. That is the point. A quality gate that can be waved through when you are in a hurry is not a gate. I break down the different kinds of test in five kinds of API test and when each one earns its place.

On the human side, giving and receiving review well is a skill in itself. My answers on how to give code review feedback without creating conflict and what to do when you disagree with a senior engineer cover the parts no pipeline can.

Stage four: deployment strategies in a CI/CD pipeline

It passed. Now it has to reach production without breaking anything that is currently running.

The naive version replaces everything at once, which works right up until the new version is broken and now everything is broken. So real deployments move gradually:

Martin Fowler's short articles on blue-green deployment and canary releases are the clearest definitions. In a blue-green setup, if anything goes wrong you switch the router back. A canary rolls the change out to a small subset of users before making it available to everybody.

Canary is the one worth understanding properly, because it is the only strategy where real production traffic tells you the truth before most of your users are exposed. Feature flags complement all three: you can deploy code switched off and turn it on separately, which separates "deployed" from "released".

The other thing that makes gradual deployment safe is backwards-compatible database changes. If version one and version two of your code run at the same time, the schema has to work for both. I cover the expand, migrate, contract approach in sixteen things that break a backend.

If you want to build this yourself, the deployment pipeline with progressive rollout and automatic rollback and pull request preview environments on a single server are strong final year projects.

Stage five: monitor

Deployment is not the end. It is the moment you start paying attention.

Watch latency, traffic, errors and saturation, the four golden signals from Google's SRE book, and compare them against the hour before your change. Most bad deployments show up in those numbers within minutes.

Alerts need an owner. An alert that fires into a channel where everyone assumes someone else is handling it is decoration. And if something does go wrong after your change, the right move is almost always to say so early; I answered that directly in made a mistake in production: tell your manager or fix it first.

Continuous integration vs continuous delivery vs continuous deployment

The words get used loosely, so here they are precisely:

• Continuous integration means everyone merges into the shared branch frequently, and every merge is built and tested automatically. Integration problems surface hourly instead of at the end of a quarter.
• Continuous delivery means every change that passes the pipeline is deployable. In Fowler's definition, you are able to deploy frequently but may choose not to, often because the business prefers a slower pace.
• Continuous deployment means every change that passes goes to production automatically, with no button. You cannot do it without continuous delivery first.

Most teams say the third and practise the second, which is fine. The distinction only matters when someone is describing what they do.

How teams measure a good CI/CD pipeline

The usual pitch for CI/CD is speed. That is the smaller half. The real function is risk reduction: small changes, tested automatically, released gradually, watched closely and reversible in minutes. Shipping faster is a side effect of the risk being lower.

The DORA research programme has the most widely used way of measuring this. Its current guide lists five software delivery metrics: change lead time, deployment frequency and failed deployment recovery time for throughput, and change fail rate and deployment rework rate for instability. The point of pairing them is that speed and stability are measured together, so you cannot "improve" by shipping faster and breaking more.

Teams that deploy ten times a day are not braver than teams that deploy monthly. They have made each deployment small enough not to require bravery.

If you are early in your career

You do not need to build a pipeline to benefit from understanding one. What you need is to stop treating the red X as an obstacle between you and merging. When a stage fails, read which stage it was:

• Build failure: your change does not compile somewhere, a dependency moved, or the environment differs from your laptop.
• Lint failure: formatting or a rule violation. Run the linter locally and fix it in a minute.
• Test failure: behaviour changed. Possibly correctly, in which case the test needs updating, but find out which before you touch it.
• Security scan failure: usually a dependency with a known vulnerability that needs bumping, or a secret that should never have been committed.
• Deploy failure: configuration, permissions or a health check. Read the logs of the new instance first.

Knowing which of those you are looking at in the first ten seconds is a genuinely useful skill, and almost nobody teaches it explicitly. If DevOps as a career interests you, read how to become a DevOps engineer in Pakistan; most of it applies wherever you are.

Learn it on Sefism

• DevOps and cloud roadmap and the DevOps and cloud cheat sheet
• GitHub Actions documentation to build your first pipeline
• DevOps with Docker and DevOps with Kubernetes for containers and deployment
• Google engineering practices for code review
• Cloud and DevOps FYP ideas
• Microservices practices that keep them workable

FAQ

What are the stages of a CI/CD pipeline?

Most pipelines follow the same shape: source change, build, test, deploy and monitor. Tests run in layers from fast linting and unit tests to slower integration tests, security scans and human review.

What is the difference between continuous delivery and continuous deployment?

With continuous delivery, every passing change is ready to deploy but a person may decide when. With continuous deployment, every passing change goes to production automatically.

What is the difference between blue-green and canary deployment?

Blue-green switches all traffic from one full environment to another, with instant rollback. Canary sends a small share of real traffic to the new version first and widens it only if metrics stay healthy.

Which CI/CD tool should a beginner learn?

GitHub Actions is the easiest place to start because it lives next to your code, and standard hosted runners are free for public repositories. The concepts transfer directly to GitLab CI, Jenkins and others.

Why do pull requests need to be small?

Small changes get reviewed properly and quickly, are easier to test and are easier to roll back. Large changes tend to be skimmed and approved with real problems still inside.

Ask your own question

If your situation is different from the ones above, the career questions library has honest answers to the questions students and engineers ask me most.

Want a learning roadmap built around you, written answers to your own questions and a place to discuss your FYP? Create your free Sefism account. Members can also book a one to one session when they want to talk it through.

Stay in touch

• LinkedIn: where I share roadmaps, career advice and honest takes on hiring. Follow, or message me.
• X (Twitter): short practical thoughts on engineering and careers.
• Instagram: quick tips and a more personal side.
• Sefism Discord: meet other students and engineers working through the same job market and share what is working.
• Sefism on YouTube: walkthroughs and talks.