CI/CD with HappyRobot: one change, three environments, driven by your Git and CI/CD

One change, three environments A change in the company's Git repo travels one road through three rings. Sandbox copy: copy the live workflow, apply the change, test, delete the copy; production is untouched. Gate: review, approve, merge in the company's tools. Staging: fork the live version, apply the merged change, publish to staging, verify. Production: publish the same version to production, verify it is live, measure; if unhealthy, republish the previous version. Failures drop to a return rail back to the change. A HappyRobot band above the rings holds the live workflow that copies and forks are taken from. Later views fade the map and add callouts for the Public API operations and for one anonymised customer's implementation. CI/CD WITH HAPPYROBOT · 01 / THE LOOPS One change, three environments. Try the change on a copy. Get it approved. Put a new version into staging, then production. CI/CD WITH HAPPYROBOT · 02 / WHERE IT PLUGS IN HappyRobot plugs into each ring. Your CI calls these HappyRobot endpoints and decides pass or fail. Review and approval stay in your tools. CI/CD WITH HAPPYROBOT · 03 / CUSTOMER 1 How Customer 1 runs it. Typed config in Git. Their CI calls the API. Staging happens on the sandbox copy; production is a fresh fork of live. HAPPYROBOT the live workflow · v12 takes calls · published versions are locked · drafts are editable copy live fork live v13 goes live PASS FAIL · PR RED · COPY DELETED FAIL · v13 NEVER GOES LIVE · FIX IN GIT NEXT CHANGE Sandbox copy throw-away copy of live production untouched Staging fresh fork of live · v13 real test calls Production v13 takes calls UNHEALTHY → v12 GitYOUR REPO ChangeONE COMMIT GateREVIEW · APPROVE · MERGE Copy Apply Test Fork Apply Stage Publish Verify Measure Your config lives in Git prompts · nodes · variables · tests, as JSON The gate is yours review · approve · merge · not HappyRobot's call API key: your secret store your CI only · never inside a workflow POST /workflows/{live}/duplicate PATCH …/variables → QA values PUT /versions/{copy}/nodes/{n} POST /versions/{copy}/test-all DELETE /workflows/{copy} POST /versions/{live}/fork → v13 PATCH …/variables → env values PUT /versions/{v13}/nodes/{n} POST /versions/{v13}/publish {staging} → run the tests there POST /versions/{v13}/publish {production, replace v12} GET /workflows/{id} → live: v13 unhealthy → publish v12 again Their repo: typed config 3 workflows · prompts · variables · evals PR green → review → merge then their CI starts the release job Key in their secret store fetched by their CI at run time only their CI, on every PR: duplicate live · inject QA secrets test-all · callback checks · evals publish copy → staging then delete the copy no separate staging ring here: staging ran on the sandbox copy merge → release job starts release job, one at a time: fork live v12 → draft v13 apply the full desired config publish production confirm v13 is live YOUR TOOLS YOUR CI CALLING THE HAPPYROBOT PUBLIC API LIVE IN PRODUCTION FAIL OR UNHEALTHY CUSTOMER-BUILT PIPELINE YOU OWNrepo · tests · review · approvals · CI/CD · secrets · release + rollback HAPPYROBOT PROVIDESPublic API · drafts · locked published versions · runtime · run/test evidence PUT NODES = WRITE YOUR CHANGE INTO THAT VERSION CUSTOMER 1 · PIPELINE IN PRODUCTION

Reading the map, and what is proven.

Black boxes happen entirely in your tools. White boxes are your CI calling the HappyRobot Public API. The one blue box is the moment a new version takes production traffic. Dotted rings are the loops; the road is the forward path; the rail underneath carries every failure back to the change.

Sandbox copy

Your CI duplicates the live workflow into a temporary copy, applies the change from your repo, sets non-production values only, runs node tests, test-all and your evals. Your CI decides pass or fail, because the platform's publish call treats some test errors as warnings. The copy is deleted whether it passed or failed. Production is never touched.

Gate

Review, approval and merge happen in your existing tools. HappyRobot is not in the approval chain.

Staging

The release job forks the current live version, not the sandbox copy: the copy held QA values, may be stale, and is a different workflow object. It applies the merged change, publishes the draft to the staging environment of the same workflow, and runs the tests there. Every workflow variable holds one value per environment, so staging runs with staging values and production with production values without a separate injection step. If staging fails, v13 never goes live; the fix goes back through Git and the next run forks live again.

Production

The same version is published to production with unpublish_version_id set to the version you expected to replace, so the call fails closed if production changed under you. Read back and record the live version. If early calls look wrong, republish the previous version; rehearse that runbook first, it is not a verified atomic transaction. Run evidence, north stars and evals feed the next change.

Evidence boundary

Sequence view