What happens between writing code and shipping a feature?

What happens between writing code and shipping a feature?

Between writing code and shipping it, a change travels a fixed path: it gets saved as a commit, built up on a branch, opened as a pull request, reviewed by teammates, merged into the shared code, tested on a staging copy of the app, and finally deployed to production, where customers use it. Every professional team runs some version of this pipeline, and most of the vocabulary in an engineering standup names one of its steps.

The earlier lessons set the scene. Code lives in a shared repository, the app it becomes has a frontend and a backend, and the finished thing runs on rented machines in the cloud. This lesson covers the middle: how a change moves from one developer's laptop onto those machines without breaking what customers already rely on.

When a change completes the whole trip, developers say it shipped. Shipping is the unit of accomplishment in software. A resume line like "shipped the checkout redesign" claims the entire path, from first commit to live customers, and hiring managers read it that way.

What is a commit?

A commit is one saved change to code. It records three things together: who made the change, when they made it, and a short written note describing what changed.

A commit differs from hitting save in a document. Saving overwrites the old version. Committing adds a new entry to a permanent record while keeping every earlier entry, so the repository holds the full history of the project: every change, in order, each one signed and described. A developer can open any file and see who wrote each line, when, and why. Developers commit several times on a working day, and small commits are considered good practice because a small change is easy to understand and easy to undo.

This history is why a public profile on GitHub says as much as it does. A developer's commits are a signed, timestamped record of work, made in the normal course of doing it. The habits visible there, how often someone commits, how clearly they describe each change, formed on real teams over years.

What is a branch?

A branch is a private copy of the code where a developer builds a change without disturbing anyone else. The shared main copy of the codebase is usually called the main branch. To start a feature, a developer creates a new branch from it, works there, and commits as they go. Teammates keep working on their own branches at the same time, and none of them collide.

The name describes the picture developers hold in their heads. History runs like a trunk, and each new line of work grows off it like a branch of a tree. Twenty developers can mean twenty live branches, each one a feature or fix in progress. When the work on a branch is done, it gets folded back into the trunk. That folding is called a merge: the branch's commits join the main branch, and the private copy has served its purpose.

What is a pull request, and what happens in code review?

A pull request is a proposed change, packaged for teammates to inspect before it merges. The developer opens one when their branch is ready. It shows every changed line side by side with what was there before, plus a written description of what the change does and why. The name is historical: the author is requesting that the team pull their branch into the shared code. The abbreviation PR is universal, and some tools call the same thing a merge request.

What happens next is code review. Teammates read the changed lines and leave comments: a possible bug, a clearer way to write something, a case the author may have missed. The author responds, pushes follow-up commits, and the conversation continues until a reviewer approves. Most professional teams require at least one approval before anything merges, and the whole exchange is written down in the PR, permanently.

Review is where engineers spend a large share of their week, and it is the part of the job that looks most like editing. Reading a colleague's work carefully, disagreeing in writing without heat, and taking criticism on your own work in public thread form are daily engineering activities. A developer's public pull requests show all of it verbatim, on both sides of the exchange.

What are development, staging, and production?

Development, staging, and production are separate running copies of the same app, called environments. Development is the copy on a developer's own laptop, where anything goes. Staging is a private copy on real servers, set up to match the live one, where merged changes get exercised with no customers present. Production is the live app, the one real customers are using right now.

The word production is why engineers talk the way they do. "In production" means real users are touching it. "Broke production" means customers felt it. When a developer says a system they built "runs in production" or "serves production traffic", they are claiming the highest tier of responsibility: their work held up in front of paying users, where mistakes are public and expensive. The phrase carries weight for the same reason "closed the deal" does. Everything before it was rehearsal.

What does deploying mean?

Deploying means copying a version of the code onto the machines that serve customers, so the new version becomes the one people use. The word comes from military usage, sending a force out into the field, and the tone fits. A deploy is the moment the team's work leaves the safety of review and staging and stands in front of the public.

A batch of changes packaged to go out together is called a release. Teams differ enormously in rhythm here. Some deploy to production many times a day, each release a few small commits. Others gather weeks of work into a large release on a schedule. Both are normal, and the cadence says a lot about how a team works: rapid deploys need heavy automation and strong testing, while slower cycles are common where mistakes are costly to reverse, as in banking or medical software. A candidate's deploy rhythm at their last job shapes their instincts about speed and safety.

Deploys sometimes go wrong, and the standard remedy is a rollback: redeploying the previous version, so customers are back on the code that worked while the team investigates. A developer who talks fluently about rollbacks has been present when a release failed in front of users, which is experience only live systems provide.

What is CI/CD?

CI/CD is the automation that runs this whole pipeline. The letters stand for continuous integration and continuous delivery. Continuous integration means every pull request is automatically checked by machines: the code gets assembled and a suite of automated tests runs against it, and a failing check blocks the merge. Continuous delivery means approved changes then move toward production automatically, without a person copying files by hand.

Before this automation, releasing software was an event. A person followed a checklist, copied files to servers in order, and hoped. CI/CD turned that ceremony into a machine that runs on every single change, which is what makes deploying several times a day possible at all. On a resume, phrases like "built our CI/CD pipeline" or "improved deploy times" describe exactly this work: constructing and tuning the machinery every teammate's changes travel through. It sits in the territory called DevOps, and the people who do it well are force multipliers, because every developer on the team ships through what they built.

The pipeline is also the reason software can be revised forever. A change that took months to release gets attempted rarely. A change that takes minutes gets attempted constantly, which is how live products keep evolving after launch and why the path you can now narrate, commit, branch, pull request, review, merge, staging, deploy, gets walked thousands of times over a product's life.