Recommended flow for testing an experience in dev before production?
I have been burned enough times by "just edit it in prod" workflows that I want a proper promotion pipeline before we let anyone publish experiences.
What I want is the CMS-style flow: build the experience against a dev environment, QA it there against real slots, then ship the identical thing to production. What is the intended way to do this with Croct? I can see workspaces have environments but I have not found a "promote" button, so I want to know what the actual supported workflow looks like before I invent my own
2 answers
The intended workflow rests on three mechanisms:
-
Environment separation. Workspaces hold multiple environments (dev and prod), each with its own application ID, and croct.json5 maps applications per environment. Your dev deployment points at the dev application, so its traffic and content never mix with production.
-
Preview links for the QA step. Before publishing in production, generate a preview link from the experience editor and review against the real slots. The preview widget shows the experience, variant, audience, and locale under review. One requirement to be aware of: the slot versions in the preview must match what the integrated code expects, so keep the environments on the same component versions during QA.
-
Per-environment publication. There is no single promote button; publication happens in each environment. The safety rails in production are the Draft status, which holds the experience unpublished until you deliberately release it, and pausing, which immediately reverts visitors to default slot content if something looks wrong after release.
So the flow is: build and validate in dev, recreate or template the setup for production, hold it in Draft, preview against production slots, then publish.
From someone running this in practice: the piece that made our pipeline feel safe was treating pause as the rollback. Publishing to prod stopped being scary once the team internalized that pausing an experience instantly serves default content, no deploy, no cache purge, just back to baseline.
Also worth committing your croct.json5 with both environment mappings from day one. We had a week where a staging deploy pointed at the prod application ID because the mapping lived in someone's local config, and the dev-traffic pollution in our audience data was annoying to reason about afterwards. In the repo, reviewed like any other config, problem gone.
Late addition but natec's two points are the ones that stuck for us too. We now write pause-as-rollback into the release checklist, so whoever ships knows the panic button reverts to default slot content instantly, no deploy and no cache purge. And a local-only croct.json5 mapping once sent staging traffic at the prod application here as well, same annoying cleanup afterward, so committing it was the fix.
One extra we added on top: keep dev and prod on matching slot and component versions during QA. Otherwise the preview link fails on a version mismatch right when you are trying to sign off, which we learned the annoying way.