A patch doesn’t leave a studio and land on a player’s machine in one step. It goes through a build pipeline first, a private test rollout second, and a content-delivery system last, and each of those stages exists because shipping software to millions of installs at once is a different problem than shipping it to the one machine a developer builds on.
The pipeline starts with a build tool that packages a game’s files into whatever format the distribution platform expects. Steam’s version, the Content Builder, organizes a game’s files into depots, containers split by platform, language, or function, then runs a script that uploads them and assigns the result a build ID. Steamworks’ own documentation is specific about what that ID means for players: a build stays private until a developer explicitly sets it live on a branch, and even then, “the default branch can not be set live automatically,” it has to be selected manually through Steam’s own admin panel. That manual step is a deliberate checkpoint, a build existing on Steam’s servers and a build reaching players’ default install are two different states, and the gap between them is where a studio does its last check before a patch goes fully public.
Before a build reaches the default branch, most studios run it through smaller, restricted audiences first, on what Steam calls branches and most players call betas. Steamworks documentation describes a branch as “specific builds of your application that you have made available publicly or privately through Steam,” and a private branch can be password-protected, restricting access to whoever the studio hands the password to. A public test realm, a public beta branch anyone can opt into, works the same way without the password: a player right-clicks the game in their library, opens its beta tab, and selects the branch, at which point Steam replaces their installed build with that branch’s build. Nothing about this differs in kind from a staged rollout on a mobile storefront, only in mechanism. Google Play’s own documentation describes a staged rollout as sending an update “to only a percentage of your users, which you can increase over time,” with the platform choosing that percentage of users at random and the developer watching crash reports before deciding whether to expand it or halt it. Both systems solve the same problem: reaching a defined, monitorable slice of the install base before reaching everyone.
What actually moves once the rollout is confirmed is not a fresh copy of the whole game. A content-delivery system, whether it’s Steam’s own network or a general-purpose CDN behind a mobile storefront, is built to send only the difference between the version already installed and the version being shipped, since re-downloading everything for every patch would be enormously wasteful of both bandwidth and player patience for a live game that patches often. That’s the same delta logic build numbers exist to track in the first place: a new build number usually means a relatively small, specific set of files changed, not that the whole game was rebuilt from nothing, and the delivery system’s job is to identify and ship exactly that difference.
Read together, these three stages explain why a patch’s public rollout can look uneven from the outside: a build id ticking up on a public test branch is a studio testing in view of a small group, a staged percentage rollout climbing over several days is a platform’s own safety mechanism working as designed, and a sudden jump to full availability is usually the studio deciding the earlier stages found nothing worth stopping for.