Loading

Versions and Rollout

Extension code is never edited in place. Every save creates a new version, and the version that runs only changes when an architect deliberately puts another one live. That makes it safe to work on a fix while the current version keeps running, and quick to go back if a new version misbehaves.

Where to find it

Architect Panel → Automation:

  • Extensions — the Versions card, status buttons and Recent runs for each extension

Architect Panel → Layout & Pages:

  • App Code — where new versions are written and checked

How a version moves to live

  1. Saved. A developer saves code in App Code. Saving creates a new version but never changes what is running.
  2. Checked. Each saved version is run through the code checker. The Gate column on the Versions card shows whether it passed. A version that failed is kept, but cannot be approved.
  3. Approved. An architect clicks Approve on the version ("Approved.").
  4. Live. The architect clicks Put live on that version and confirms "Put this version live? It will start running immediately." The message reads "Published v" and the version number. Putting a version live also clears the circuit breaker.

In App Code, an architect's Publish button does the approve and put-live steps together. The Versions card lists Version, Gate, Origin, Author and Approved for each one, so you can see who wrote what and whether it was checked.

Rolling back

To go back, click Roll back to this on an earlier version. It is subject to the same rules as any other version going live: it must have passed the current code checker and been approved. The message reads "Rolled back to v" and the version number. Nothing is lost; the later versions stay in the list.

The status buttons

  • Put live: runs the current published version. Refused if no version has been published yet ("There is no published version to run").
  • Disable: stops it immediately ("Disable this extension? It stops running immediately.").
  • Back to draft: takes it out of service while it is reworked.
  • Dry-run mode: marks it as under test. Despite the name, an extension in this status does not run on real events; only live extensions run. Test a version with Dry run in App Code instead.
  • Remove: deletes the extension but keeps its version history ("Removed. Its version history is kept.").

Testing before going live

App Code's Dry run runs the code once without writing anything and without sending anything, and shows the result. It runs with no record supplied, so it proves the code runs, not that it handles every real record. After putting a version live, watch Recent runs for failures; every failure is recorded there.

What goes wrong and how to tell

  • "This version has not passed the code checker, so it cannot be approved.": have the developer fix the findings and save again.
  • "This version was checked by an older version of the code checker.": after a platform update, save the version again in App Code to re-check it, then approve.
  • "This version has not been approved yet.": approve before putting it live.
  • The same person wrote and approved a version: the screen does not prevent this. If you want a second pair of eyes, make it your own rule.

Worked example

Version 4 of an extension is live. A developer saves version 5 with a change to the wording it draws; the Gate column shows it passed. The architect reads the code with the developer, clicks Approve, then Put live. Ten minutes later Recent runs shows errors on records with an empty date. The architect clicks Roll back to this on version 4, the errors stop, and the developer saves version 6 with the empty case handled.

Recommendations

  • Approve someone else's code, not your own, as a matter of practice.
  • Keep the previous version approved so a rollback is one click.
  • Watch Recent runs after every change going live.
  • Use Disable, not Dry-run mode, when you simply want it off.