This is the machinery that turns a ticket into software real people use. Every technical role needs to understand it, including the ones that never write code.
It looks like a lot of separate rituals. It is really one question asked repeatedly: how do we change something people depend on, without breaking it?
Learning Objectives
After this lesson, you will be able to:
Explain what code review is for, and what makes a review useful rather than obstructive
Describe the testing pyramid and why its shape is that way round
Walk the environment ladder from a developer's machine to production
Say what happens during an incident, and what a blameless postmortem is for
A reviewer catches what you could not see in your own work. Automated tests catch what nobody thought to check by hand. Environments catch what only shows up with realistic data. A rollback plan catches the case where everything passed and it broke anyway.
None of these is bureaucracy. Each is a scar. When a practice looks excessive, the useful question is what went wrong badly enough that someone invented it.
Every change is read by at least one other person before it joins the main codebase. Most teams enforce this automatically, so an unreviewed change simply cannot merge.
It exists for three reasons at once. It catches bugs while they are still cheap. It spreads knowledge, so more than one person understands each part of the system. And it keeps the codebase looking like it was written by one team rather than by twelve people who never spoke.
If you are reviewing
Review promptly. A pull request waiting on you is a colleague who cannot move forward.
Comment on the code rather than the person. "This will fail when the list is empty" and "you forgot the empty case" say the same thing, and only one of them is comfortable to receive.
Separate the blocking from the optional. Teams often prefix the latter with "nit:", meaning this is a preference, do not let it stop you. Without that signal, authors cannot tell what actually needs fixing.
Approve when it is good enough. Reviews that hold out for perfect are how teams stop shipping.
If you are the author
Keep changes small. A couple of hundred lines gets read properly; two thousand gets skimmed and approved, which is worse than no review because everyone believes it was checked.
Write a description that says what changed and why, and link the ticket. The reviewer should not have to reconstruct your reasoning.
Respond to every comment, even if only to say you disagree and why. Silence reads as ignoring it.
The pyramid is a claim about proportions: many fast tests at the bottom, few slow ones at the top.
The testing pyramid, top to bottom
End-to-end — dozensDrives the whole system like a real user would. Slow, and breaks for reasons unrelated to your change. Keep few.
Integration — hundredsChecks components work together: an API with its database, a service with its queue. Catches wiring problems unit tests cannot see.
Unit — thousandsTests one function or class alone. Runs in seconds, points straight at the broken line, written by developers alongside the code.
The shape follows from cost. A unit test runs in milliseconds and tells you exactly what broke. An end-to-end test takes minutes, and when it fails you still have to work out where. Both are worth having; you just want far more of the cheap, precise ones.
Around the pyramid sit several other kinds. Smoke tests are a quick "is it alive" check straight after a deployment. A regression suite confirms that things which used to work still do. Performance tests check it holds up under load. Security scans look for known vulnerable patterns and dependencies. Accessibility tests check it can be used with a screen reader and a keyboard. User acceptance testing is the business confirming it does what they asked for.
You will also hear shift left, meaning move testing earlier. A misunderstanding caught while writing the requirement costs a conversation. The same misunderstanding caught in production costs an incident.
What Do You Think?
A team has 40 end-to-end tests and 12 unit tests. The suite takes 25 minutes and fails intermittently for reasons nobody can reproduce. What is the underlying problem?
Build a test suite and see what it costs youInteractive
Set how many tests of each kind the suite has. Watch run time, flakiness, time-to-diagnose and coverage move together — the pyramid's shape is what falls out of those trade-offs, not a rule handed down.
Loading visualization...
Try to reach "healthy" using end-to-end tests alone. It cannot be done, and failing to do it is more convincing than the diagram: they are too slow to run often and too noisy to trust, so the confidence has to be bought lower down where it is cheap.
Code climbs a ladder before it reaches users. Each rung adds realism and removes freedom.
From your machine to real users
ProductionReal users, real data, real money. Changes are controlled and every deployment has a way back.
Staging / Pre-productionAs close to production as it gets. Final check before release, often where performance is measured.
UATBusiness users confirm it does what they asked. Production-like data, usually masked.
QA / Test / SITWhere QA verifies merged work and components are tested together. Controlled test data.
Local / DevYour own machine or a shared dev server. Synthetic data. Break things freely.
Two rules govern the ladder in almost every company.
Real customer data does not travel downward. Production data in a test environment is one of the more common causes of serious data-protection incidents, which is why UAT data is usually masked.
Changes travel upward in order, and skipping a rung is a decision someone senior makes deliberately during an emergency, not a shortcut taken quietly.
Continuous integration means every change is automatically built and tested the moment it is pushed. The point is speed of feedback: you find out in minutes rather than at the end of the sprint. When someone says "CI is red", the automated checks failed and nothing should merge until it is green again.
Continuous delivery means every change that passes is ready to release, with the release itself remaining a human decision. Continuous deployment goes one step further and releases automatically. The difference is one button, and which one a company chooses says a lot about its risk appetite and its regulator.
Two release techniques worth recognising. A blue-green deployment runs two identical production environments and switches traffic between them, so undoing a bad release is a switch rather than a rebuild. A canary release sends the new version to a small percentage of users first and watches the numbers before widening it.
An incident is an unplanned interruption. Most companies grade them by severity, where the top level means everything is down and the lower levels mean something is degraded or inconvenient.
The rhythm is consistent. Someone or something detects it. A person takes ownership of coordinating. The immediate priority is restoring service, which frequently means rolling back rather than fixing forward, because a known-good previous version beats a hurried repair. Updates go out while it is happening, because silence during an outage is its own problem. Once service is restored, the actual cause is investigated properly.
That last step produces a postmortem or root cause analysis, and the word attached to it is blameless. The premise is that if people are punished for causing incidents, they stop reporting them, and the organisation loses the information it needs to stop the next one. The question is what in the system allowed a reasonable person to make that mistake, rather than who made it.
On-call is the rota for who responds outside working hours. It is normal in teams that run their own services. Whether it is paid varies a great deal: some countries require a standby allowance by law, many Indian employers pay a defined shift or on-call allowance, and at a lot of US and startup employers it carries no extra pay because it is treated as part of a salaried role. There is no single industry norm, which is exactly why it is reasonable to ask before you accept a job how often the rota comes round, what the response-time expectation is, whether it is compensated, and whether you get time back after a bad night.
Quick Check1 / 3
A release has caused errors for a portion of users. The team thinks they know the cause and could push a fix in about forty minutes. What should happen first?
Every practice here answers one question: how to change production without breaking it. Each is a response to a specific past failure.
Review catches what the author cannot see, spreads knowledge, and keeps the codebase coherent. Small changes get real reviews; large ones get rubber-stamped.
The testing pyramid is about proportions: many fast precise tests, few slow broad ones. Inverting it produces a slow suite nobody trusts.
Code climbs environments from a developer's machine to production, gaining realism at each rung. Customer data does not travel back down.
When production breaks, restore service first and investigate second. Postmortems are blameless because blame destroys the reporting the organisation depends on.
Next: Corporate Processes — timesheets, contracts, appraisals and status reporting, and why the answers to all of them trace back to how the company makes money.