Build in QA, promote to prod — never edit the same pipeline twice

DMM Infinity has no "production safe-mode". The only thing standing between you and an accidental write to prod is the target you picked five minutes ago.

4 min read

DMM Infinity treats every environment the same way the agent does: as a remote target it can read from and write to. There is no warning banner when the target is production. There is no separate "production pipelines" section. The pipeline list shows pipelines; a small target name in the corner is the only thing telling you what each one will write to next.

The pitfall in one line
A pipeline that ran cleanly against QA eleven times in a row will, on the twelfth run, do exactly what you configured it to do — and the configuration is whichever target is selected right now.

Why this happens

Pipelines in DMM Infinity are a single editable artefact. The Source Environment, Target Environment, and Write Strategy are properties of the pipeline, not of the run. Anyone with access to the pipeline can change any of them, save, and walk away. The next person to hit Run inherits whatever the last edit left behind.

The product makes this easy on purpose — iterating on a pipeline across QA targets is exactly what you want early. The risk shows up at the moment you decide a pipeline is "ready" and start using it for real work without changing your editing habits.

The promotion pattern

Build, run, and verify your pipeline using a non-production environment as the target. When you are satisfied with entity selection, write strategy, and record counts in the run details, treat that pipeline as frozen. Create a new pipeline (clone or rebuild) for the production target. Name it explicitly. Run it through review. Never touch the QA version's target again.

Do
  • ·Maintain one pipeline per target environment, named accordingly: "Copy CRM (→ QA)" vs "Copy CRM (→ Prod)".
  • ·Add the target environment name in the pipeline title — your eyes will read the title before they read the corner.
  • ·Treat production pipelines as frozen artefacts: no live edits, only versioned changes.
  • ·Require a second pair of eyes on any production pipeline change, even cosmetic ones.
Don't
  • ·Edit a single pipeline back and forth between QA and Prod targets.
  • ·Save a pipeline with target=Production and walk away — anyone with access can hit Run.
  • ·Assume "I know which one I am editing" survives a tab reload, a context switch, or three meetings.
  • ·Skip the source/target check at the top of the Select Environments step. Read it twice.

A concrete example

A CRM team built a "Copy CRM" pipeline that flipped between QA and Production targets depending on whose turn it was. After eleven successful QA runs and three months of confidence, an end-of-quarter cleanup task opened the same pipeline, swapped the strategy from Insert to Clean to "tidy up the staging tables", saved, and ran it. The target was still Production from the previous demo.

Forty-seven thousand customer records vanished in six seconds. The audit log showed a successful run. Recovery required a database restore from a backup taken four hours earlier; the four hours of writes in between were reconstructed by hand from CRM email threads.

Rule of thumb
One pipeline per target. Production pipelines are a small, named, reviewed set — not the same pipeline you were iterating on yesterday.
Still need help?
If this article does not solve it, the DMM Infinity team is one ticket away.
Submit a ticket