Parallel Change¶
Sato, D. (2014). Parallel Change. martinfowler.com.
Cited by¶
6 citations across 6 artifacts.
Each citation links to the sentence it supports in the citing article.
Mechanisms¶
- Migration Runbook Notice
- Built as a parallel-change ("expand and contract") migration
This source(2014). Parallel Change. martinfowler.com, 13 May 2014. https://martinfowler.com/bliki/ParallelChange.html Defines parallel change, or expand and contract, as supporting old and new interfaces together while clients migrate incrementally, reducing risk and permitting staged release.
- Built as a parallel-change ("expand and contract") migration
- Rolling State-Migration Workflow
- Its signature failure is the migration that expands but never contracts
This sourceWarns that omitting the contract phase leaves both old and new versions supported and can produce a worse state than before migration.
- Its signature failure is the migration that expands but never contracts
- Safe Consistency Migration Workflow
- The distinguishing structure is expand/contract applied to semantics: add the new behavior alongside the old, migrate consumers gradually, then remove the old — so no single step is a breaking flip.
This sourceDefines parallel change as an expand-migrate-contract sequence that keeps old and new interfaces available during a gradual migration.
- The distinguishing structure is expand/contract applied to semantics: add the new behavior alongside the old, migrate consumers gradually, then remove the old — so no single step is a breaking flip.
- Schema Migration Runbook
- The discipline is to define the trigger and the done-state up front, verify before each cutover, and always complete the contract phase — the expand-and-contract (parallel change) pattern run to its end, not abandoned in the middle.
This sourceDefines parallel change as a complete expand–migrate–contract sequence for safely evolving an interface.
- The discipline is to define the trigger and the done-state up front, verify before each cutover, and always complete the contract phase — the expand-and-contract (parallel change) pattern run to its end, not abandoned in the middle.
- Schema Migration Workflow
- Its whole safety rests on the expand-and-contract (parallel-change) pattern: first add the new shape alongside the old and run both, then migrate consumers, then remove the old, so there is never a moment when the system depends on a half-applied change.
This sourceSato’s expand–migrate–contract sequence keeps old and new forms compatible until consumers have moved, then safely removes the old form.
- Its whole safety rests on the expand-and-contract (parallel-change) pattern: first add the new shape alongside the old and run both, then migrate consumers, then remove the old, so there is never a moment when the system depends on a half-applied change.
- State Migration Playbook
Verification¶
Does it exist? Not checked yet. This entry carries no identifier to resolve. It was extracted from the citation as written in the article, normalized, and deduplicated against the rest of the registry.
Does it back the claim? Not recorded. Neither this nor any other of the 6 citations of this work carries a recorded support check.
Support is checked per citation rather than per work — the same source can be cited soundly in one article and wrongly in another. Per-citation recording began recently, so a citation with no recorded check is a gap in the record rather than evidence it went unchecked.
See how references were verified.
Registry ID ref:7ba0342fa80e · see in the full table