CI test data: give each run an isolated ownership scope

Last updated: 5 Oct 20266 min read

tutorial

An integration test that writes to a shared database, queue, object store, or account can affect another test run. The resulting failure depends on timing and execution order rather than the candidate code. Isolation requires a scope that follows the test through every external system and is removed after use. A unique name in one database table is insufficient if the same test also publishes to a common queue or reads a global cache.

Operational decision

Two receipt branches test settlement against one staging database and intermittently see each other's rows. Give each run a validated identifier and a dedicated schema or disposable database, plus queue topic, object prefix, and idempotency-key namespace derived from that same identifier. The policy fragment lists the boundary. Run the same suite twice in parallel with overlapping customer IDs and verify that neither run can observe or consume the other's records. Force one run to crash before cleanup, then have a janitor remove only expired scopes after checking ownership and retention; never let a broad delete pattern reach another run or production. Where a third-party sandbox cannot create per-run accounts, serialize the dependent tests or replace that integration with a deterministic local substitute and retain a separate contract check. Capture the scope ID in failure reports, but keep secrets and customer payloads out of artifacts.

Receipt CI run scope
Identity: trusted run ID plus attempt number
Database: isolated schema or disposable instance
Queue: per-run topic or consumer group
Objects: per-run prefix with owner tag
Cache and idempotency: same run namespace
Cleanup: exact scope only, after retention window
Failure report: scope ID and revision, no customer data

Cost and verification

Disposable databases and queues cost time, storage, and service quota; shared resources are cheaper until they create false failures or data leakage. Scope cleanup also needs a failure path for canceled jobs. Measure cross-run collisions, orphaned scopes, cleanup latency, and the time needed to provision isolation. If tests must share one external sandbox, limit concurrency explicitly and document that bottleneck rather than pretending the test suite is parallel-safe.

Common Mistakes

Do not use a fixed customer ID across simultaneous runs.
Do not clean up with a broad prefix that may match another run.
Do not isolate only the database while sharing queues, caches, or external accounts.

Connected lessons

Practice and check

devops

operations