Deployment & Where Software Runs
Deployment is the act of putting the built artifact somewhere users can actually reach it — a server, a container, a cloud platform. Where and how software runs shapes everything about operating it. (The cloud itself is the subject of the Cloud from Zero course; here we keep it at the concept level — what running software means and why it matters.)
Deployment is the bridge from "it's built and tested" to "real people are using it". After this, the software is live, and the work shifts from building it to keeping it running.
A theatre analogy fits: opening night. After all the rehearsals (your testing and staging), the show finally runs in front of a paying audience — and now everything counts for real.
What Deployment Is
Deployment takes the artifact from Chapter 10 and gets it running in production — installed, started, and reachable by users. It's the moment the thing you built becomes a thing people use. In mature teams it's a routine, automated, low-drama event that happens often; in less mature ones it's a tense, manual ritual. Either way, deployment is the doorway from your machines to the world.
Where It Runs
Software has to run somewhere: on a plain server (a computer that's always on), inside a container (a lightweight package that bundles the app with what it needs to run), or on a managed cloud service that handles much of the machinery for you. You don't need the details here — just the idea that "production" is a real place, made of real computers, that the cloud and DevOps courses explore fully.
Automated Deployment
The best teams don't deploy by hand. A script or pipeline does it — the same way, every time — so deployments are repeatable and boring rather than risky and stressful. This connects straight to the continuous integration and delivery from Chapter 10 and to the DevOps course: automation is what turns deployment from a scary event into something a team can do many times a day without fear.
Production Is Different
Production is not just a bigger test environment — it's where real users and real data live, with real consequences. A mistake here loses someone's work, leaks their data, or costs money and trust. That's why everything in this chapter — watching the system, setting reliability targets, responding to incidents — exists. Production is where the stakes become real, and respecting that is the heart of operating software well.
The reminders artifact is deployed to Cadence's cloud-hosted production environment by an automated pipeline — the same steps, every release, no manual fumbling. From this moment, real users' streaks depend on it staying up. The team didn't hand-copy files to a server; they pushed a button and the pipeline did the rest, identically to every previous deploy. That repeatability is what lets four people run a real product.
- "Deployment is a scary, manual, one-off event." Mature teams automate it into a routine, boring non-event they do many times a day. The fear comes from doing it rarely and by hand.
- "Where software runs doesn't matter to developers." It shapes configuration, scaling, and how you debug problems. Knowing your software runs on real machines in production is part of operating it well.
- "Deploying and releasing are the same." You can deploy code without releasing the feature to users — feature flags (Chapter 10) separate the two. Deployment puts the code there; releasing turns it on.
- Deployment opens the most-overlooked half of the lifecycle — running software — which is where most of a system's life is actually spent.
- Knowing that production is a real place of real machines connects cleanly to the cloud and DevOps courses, where you learn to operate it.
- Understanding that production carries real stakes explains why the rest of this chapter — observing, measuring, responding — exists at all.
Knowledge Check
What is deployment?
- Putting the built artifact somewhere users can reach it, in production
- Writing the original source code that makes up the whole application itself
- Running the tests to confirm the software works correctly
- Designing the layout of the app's screens for its users
Where might software run in production?
- On a real server, in a container, or on a managed cloud service
- Nowhere physical at all — production is only an abstract concept
- Only on each individual developer's own personal laptop computer
- Inside a branch in version control where the code is stored
Why do mature teams automate deployment?
- So it's repeatable and boring rather than risky and stressful each time
- Because automating it somehow makes the finished program run much faster
- Because a strict rule forbids deploying any software by hand
- Because automating the deploy removes the need to test the code
Why is production "not just a bigger test environment"?
- It has real users and data, so mistakes there have real consequences
- Because production servers are simply much more powerful machines
- Because production is the place where the developers actually write the code
- Because no testing of any kind ever happens before production
You got correct