**Parent Topic**: [[System Design/README]] Google defines a **launch as any new code that introduces an externally visible change** to an application. Under that definition, Google performs **up to 70 launches per week**. Server-side rollout — rather than shipping software to individual customer workstations — is what makes this cadence possible. This high rate creates both the *rationale* and the *opportunity* for a streamlined launch process, a key insight: - A company that launches once every three years **doesn't need** a detailed launch process: by the next launch, most of the prior process is already outdated. - It also **can't build** a good one — it never accumulates enough launches to generate a robust, mature process. Frequent launching is therefore self-reinforcing for reliability: only organizations that launch often both require a launch process and have the repetition needed to refine one. A launch's characteristics — the combination of attributes, the timing, the number of steps, the complexity — determine how heavyweight the process must be. So the same framework has to stretch from trivial feature flags to high-risk, multi-team launches. *Source: [[Site Reliability Engineering]] — Ch 27 — Reliable Product Launches at Scale*