Every design change, bug fix, and new feature reaches users through a deployment, and how a team deploys shapes how safely it can change its product. Deploying used to be a rare and risky event; many product teams now ship small changes several times a week, which changes what designers and product managers can ask for. The deployment process decides how fast a product can learn, because a change that cannot be shipped and measured cannot teach anything.
In this glossary topic:
What is a software deployment?
A software deployment is the act of putting a built version of software into an environment where people or other systems can run it. The version might be a web application pushed to the servers that serve customers, a mobile build submitted to an app store, or an internal tool copied to a staging server for testing. Whatever the target, the deployment is the step at which code stops being a file in a repository and starts being a running product.
In day-to-day use the word covers the whole procedure around that step: packaging the build, moving it to the target, updating configuration and databases, switching traffic to the new version, and checking that it works. Teams automate most of this through a deployment pipeline, so that a merged change moves through the same tested sequence every time. A deployment is a change to a live system, which is why the practice is organized around limiting what can go wrong and recovering quickly when something does. The Putting It on the Internet lesson walks through what deploying means for a first project, from hosting to a public address.
How does deployment differ from build, release, and delivery?
Four words get used as if they were one. A build is the compiled, packaged output produced from source code; it is an artifact, not an event. A deployment puts that artifact into an environment. A release makes a capability available to users, and it can happen at the same moment as the deployment or long after it, if the feature sits behind a switch. Delivery, as in continuous delivery, describes a team's ability to deploy any change at any time, with every build kept in a releasable state.
The distinction that matters most for product teams is between deploy and release. Many teams now separate them, deploying code dark and releasing it to users when the product, the support team, and the marketing plan are ready. Deploying is an engineering decision; releasing is a product decision, and keeping them apart gives both sides room to work. Release management is the practice that coordinates the second half of that split.
Which environments does software move through?
Most teams run at least three environments, and a change travels through them in order. The development environment is where engineers run the code on their own machines or in disposable sandboxes; it is allowed to be broken. The staging environment is a copy of production, with production-like data and configuration, where the whole product can be tested as users will meet it. Production is the live system that real users depend on. Some teams add a preview environment per change so reviewers can open a branch in a browser before it merges.
The environments exist to catch problems early, where they cost little. Each environment answers a different question: development asks whether the code runs, staging asks whether the product works, and production asks whether users are served. For designers, staging is usually the first place a built feature can be reviewed against the design, and the moment for design QA is before the change leaves it, not after it reaches customers.
What are the common deployment strategies?
A deployment strategy is a plan for how the new version replaces the old one, and the strategies differ mainly in how much risk they accept at once. A recreate deployment stops the old version and starts the new one, with a short outage in between; it is simple and still common for internal tools. A rolling deployment replaces servers a few at a time, so both versions run together briefly and the product never goes fully down.
A blue-green deployment keeps two identical production environments and switches traffic from one to the other, so rollback is a switch back. A canary deployment sends the new version to a small share of users or servers first, watches error rates and performance, and widens the share only when the signals are clean. Feature flags are not a deployment strategy in the strict sense, but they change the picture: with a flag, the code is deployed to everyone and the feature is turned on for chosen groups, which is how a staged rollout becomes a product tool rather than an infrastructure one. The strategies trade simplicity for the ability to limit and reverse damage, and larger products tend to move along that scale as the cost of an outage grows. The vocabulary of alpha, beta, and general availability that sits on top of these mechanics is covered in the Product Lifecycle & Launch Terms lesson.
What does deployment mean for designers and product managers?
Picture a redesigned checkout ready to ship. Not long ago the question was when to deploy it; now the question is how to release it, and the answers come from the deployment toolkit. Feature flagging lets the engineering team deploy the new checkout dark, so the product manager can turn it on for internal staff, then for a beta group, then for a percentage of traffic, and turn it off in seconds if conversion drops. A staged rollout turns the release into a measurement: the old and new checkout run side by side for comparable users, which is the same structure A/B testing needs.
The process also creates two deadlines designers should know. The first is the review window: once a change reaches staging, there is a short period in which a design review can still change what ships without delaying the deployment, and after it the fix becomes a follow-up. The second is the release itself, which needs release notes, an in-product changelog, or an announcement that explains the change in users' terms. A design is not finished when it is built; it is finished when it is released, measured, and explained. Designers who know where a change sits in the pipeline can time both.
What can go wrong during a deployment?
Deployments fail in predictable ways: a configuration value that differs between staging and production, a database migration that locks a table under real load, a dependency that behaves differently on the live servers, or a feature that works for the testers and breaks on a device nobody tested. The failure is rarely the code alone; it is the code meeting an environment it has not met before. Monitoring exists to catch these moments, by watching error rates, response times, and key product metrics in the minutes after a deploy.
The standard response is a rollback: returning the environment to the previous version, either by redeploying the last known good build or by switching traffic back. A rollback fixes the symptom; a hotfix, a small targeted change deployed outside the normal cadence, fixes the cause. For product teams, the rollback plan is part of the release plan. A change that cannot be undone quickly should not be released widely, and a staged rollout is valuable precisely because it limits how many users a bug reaches before the signal to roll back arrives. Weighing that risk against the cost of waiting is the trade-off the Execution lesson works through, with small continuous releases on one side and large coordinated launches on the other.
