We are hiring. See the roles

Trust & security / Process

How changes reach production.

A change should be understandable before it ships, checked before it reaches customers, and reversible if it goes wrong. This is the process for our own apps: the Nomad hub, the client portal, Iris, our website and our assessment app.

Version 1.1 · 8 October 2026 · Owned by the directors

01

Record the change

Every change to our systems is made on a branch and opened as a pull request. The pull request names the change and the reason for it, and keeps the record of what was checked. Secrets stay out of source control, and every pull request is scanned for them.

02

Check it automatically

A pull request cannot merge until its automated checks pass: type checks, linting, the test suites and a full build. A change to a database is a versioned file in source control. For the hub and the client portal, the checks build a fresh copy of the database from those files.

03

Run it in a test environment first

A merged change goes first to a separate test environment with its own database and its own test data, not customer data. For the hub and the client portal, database changes are applied there automatically. Outside production, outgoing email goes only to an internal address or is not sent, and live payment and bank connections are off.

04

Release on purpose

Production changes only through a release workflow that a named director starts. It refuses anyone else. It records the exact commit, tags the release, and checks that the system is healthy once it is live. For the hub and the client portal it also applies the release's database changes, and nobody makes them by hand. Iris's database is moving to the same setup; until then an engineer applies its reviewed changes.

05

Roll back if needed

If a release causes harm, we redeploy the last good version, which takes seconds. A database change is reversed by a new, reviewed change, never by editing the past. We check the restored behaviour and record what happened.

06

Handle urgent fixes

An urgent fix can go straight to production through its own pull request, with the same automated checks. The same fix is then carried back into the main line of work, and the next release is blocked until it has been.

The change record is the pull request, its check results, the tagged release and its health check. We update this process when the delivery workflow changes. For the full written process or a security review, email privacy@nomad.sc.