Protocol
Dry-run the real-shaped input without the real write
Real data can teach you something before it is allowed to change anything.
When it fits
- Test fixtures are too clean and production data shape is a major source of risk.
When to avoid it
- A dry run may miss write-side triggers, locking, permissions and downstream side effects; test those separately before assuming full equivalence.
Why it matters
Run the transformation or decision logic on production-shaped input while suppressing authoritative writes. Capture proposed outputs, errors, counts and performance, then compare them with the live or expected path. This is especially useful for data pipelines, migrations and agent workflows whose failures depend on real input diversity.
Steps
- The dry run receives representative production-shaped input.
- Authoritative writes and external side effects are disabled or redirected safely.
- Outputs and failures are captured for comparison.
- Differences are reviewed before live mutation is enabled.
- Sensitive production data remains protected under the same access rules.
An example
Run a customer transformation against current records into a temporary table and compare the proposed target fields before enabling update mode.
Check your result
The team has evidence from realistic input without yet exposing the authoritative target to the change.
Keep this limit in mind
- A dry run may miss write-side triggers, locking, permissions and downstream side effects; test those separately before assuming full equivalence.
Evidence and sources
Google SRE describes dry-run or canary pipeline execution that uses production data while skipping writes to production storage.
A no-write path may not exercise all write-side constraints, triggers or downstream effects.
Improve and Optimize Data Processing Pipelines · Canarying data pipelines; two-phase mutation