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.