Testing and Shipping to Users
Writing the code is only half the job. The other half is getting that code onto the servers people actually use, without breaking anything that already worked. A change that lives only on the developer's laptop helps no one — it has to travel, safely, all the way to you.
Teams handle this with a repeatable sequence: check the change, package it, and put it where users can reach it. Each step has a name and a clear job, and together they explain how a fix or a new feature gets from someone's keyboard to your screen.
Testing: did the change break anything?
Code is a set of exact instructions, and a small change in one place can quietly break something somewhere else. Testing is how a team catches that before users ever see it. A test is a check that runs the software and confirms it still does what it should.
Most of these checks are automatic. The developer writes them once, and from then on the computer re-runs the whole batch every time the code changes — often hundreds or thousands of checks in a few seconds. If any one of them fails, the team knows immediately, and which part broke.
That speed is the point. A person testing a large app by hand would miss things and take hours; the same checks run automatically catch a broken login the moment it breaks. Manual testing still happens for things only a human can judge, but the routine checking is handed to the machine.
Building: turning code into the thing that runs
The code a developer writes is not yet in the form a computer runs. Earlier in this course you saw that source code — the human-readable instructions — has to be turned into something the machine can execute. Building is that step: it takes the raw code and produces the finished, runnable program.
Building also gathers everything the program needs to run — its pieces, its settings, the other code it depends on — and bundles them into one package ready to be sent somewhere. After a build, you have a single thing to ship rather than a scattered folder of source files.
Shipping: putting it where users can reach it
A built program sitting on a developer's laptop still helps no one. It has to go onto the servers that real users connect to — the always-on computers from earlier in the course that wait for requests and answer them. Putting the new version onto those servers is called deploying, or shipping.
This is the moment the change becomes real for everyone. The next time you open the app or refresh example.com, your browser talks to those servers and gets back the new version. Nothing changed on your device — the software changed on the servers you reach.
Automating the whole line
Doing test, build, and deploy by hand every time is slow and easy to get wrong — and a team might ship many changes a day. So they automate the sequence: one change triggers the checks, then the build, then the deploy, with no one babysitting each step. This automated test-build-deploy pipeline is what the industry calls CI/CD.
Picture a factory line. A product moves down the belt and at each station it's inspected, assembled, and boxed the same way every time, so what reaches the customer is consistent. The pipeline does the same for software: every change goes through the same checks and the same packaging before it ships — but unlike a factory, it can run the whole line in minutes and many times a day.
- "The moment code is written, users have it." Not even close. A change still has to be tested, built, and deployed to servers before anyone but the developer can use it.
- "Testing is optional, and always done by hand." Most testing is automatic and runs on every change; skipping it is how broken software reaches users. Manual checks add to it, they don't replace it.
- "Deploying and writing code are the same step." Writing code changes the instructions; deploying puts the built result onto the servers. They're separate jobs, often done by different tools.
- "Updating an app means downloading a new app every time." For a website, the new version usually goes onto the servers — your browser just gets it. Nothing is installed on your device.
- This test-build-deploy idea is the heart of DevOps and CI/CD — whole courses and job titles exist for it, and you've now met the core picture.
- It explains why apps and sites improve so often: an automated pipeline lets teams ship small changes safely, many times a day.
- It's why "it works on my machine" isn't enough — software has to pass the same checks and the same build before it reaches you.
- When you later meet tools like GitHub Actions, you'll recognize them as the machinery that runs exactly this pipeline.
Knowledge Check
In what order does a code change typically reach users?
- Test the change, build it into a runnable program, then deploy it to the servers
- Deploy it to all users first, then build it, and only finally test whether it worked
- Build it, deploy it to users, and only afterward run any tests on it
- Deploy it, then test it, and build it once users report a problem
What does testing a change actually do?
- It turns the human-readable code into the finished program that the machine runs
- It checks that the change works and didn't break anything that worked before
- It places the new version onto the servers so that users can start reaching it
- It records who made each change so the team can rewind the history later
Why do teams automate the test-build-deploy sequence into a pipeline?
- So they can skip testing entirely and ship changes straight to users
- So every change goes through the same checks the same way, quickly and many times a day
- So the computer writes all of the code for them and the developers no longer have to do it
- So no human is ever involved in building software at any point
You got correct