Versions and Rollout
An extension carries a current version and a draft, so changes can be prepared without affecting what is running.
Where to find it
Architect Panel → Automation:
- Extensions — the extension registry, its versions and runs
Architect Panel → Layout & Pages:
- App Code — the in-browser editor
Architect Panel → Activity:
- Error Log — failures after a change
Draft and current
The running code is the current version. A draft is what you are working on, and it does not affect anything until it is promoted.
That separation is what makes editing a live extension safe. Without it, every save is a deployment.
Work in the draft
Always, even for a small change. "It is a one-line fix" is how a production extension gets broken, and the cost of using the draft is nothing.
Test before promoting
An extension runs against real data on real records. Exercise the change against realistic input — including the awkward cases — before it becomes current.
Particularly test what happens with missing or malformed data, because that is what production will supply eventually and it is what the previous version had learned to survive.
Promote deliberately, and watch
Promotion is a deployment. Do it when somebody is available to notice a problem, not at the end of a Friday, and check the error log afterwards rather than assuming.
The circuit breaker will contain a badly broken version; it will not tell you about one that is subtly wrong.
Rolling back
Versions are retained, so reverting is possible. Know how to do it before you need to — the moment an extension is misbehaving in production is not the moment to be working out the mechanism.
Watch the first runs
Extension runs are recorded, so after promoting you can see whether it is being invoked and whether it is succeeding. That is a more direct answer than waiting for somebody to report a problem.
Changing what it binds to
More consequential than changing the code. Rebinding an extension changes where it runs, so it may start acting on records it never has — with logic written for something else.
Treat a binding change as a bigger change than a code change, which is the opposite of how it feels.
Keep versions meaningful
Note what changed and why. An extension with fifteen versions and no record of what each did is one nobody will dare roll back, because they cannot predict what they would be reverting to.
Worked example
A team edits an extension in its draft, tests against a copy of real referrals including three malformed ones, promotes on a Tuesday morning and watches the runs. A subtle error found an hour later is reverted to the previous version in under a minute, fixed in the draft, and promoted again the next day.
Recommendations
- Always work in the draft, however small the change.
- Test with malformed data, not just good data.
- Know the rollback before you promote.
- Treat a binding change as bigger than a code change.