Platform and Apps · Daily operations · 9 min read

Approve and activate a release

Have independent approvers sign a staged release, then activate it inside the maintenance window with a verified backup in hand.

Before you begin

The release is Staged: see Prepare and submit a release. Approval is by an independent approver: someone who did not create, submit or stage the release. This applies to superusers as well.

The number of approvers needed comes from the release policy (1 to 3 different people). Check it on the release before you start.

Approve

1. The approver opens Platform > Releases > Releases and opens the staged release.
2. Read the Details, Packages, Gates and Evidence tabs, including the SBOM, the upgrade rehearsal and the rollback plan.
3. Press Approve.
4. Enter the QA disposition, for example 'UAT passed on staging 2 Oct'. It is required.
5. Tick I have read and accept the rollback plan. Without the tick the approval is refused.
6. Press OK.

If the policy needs two approvers, the first approval leaves the release Staged with Approvals 1/2 and a history entry. The same person approving again is refused: 'You have already approved this release.' The second, different approver completes it.

Anyone who prepared the release is refused: 'Somebody other than the person who prepared this release must approve it.'

What happens next

The release is Approved. The system writes a signed manifest containing the package lines, the artifact hash, the migration head, a digest of the rollback plan, the QA disposition, the approvers, the SBOM, the provenance and the core version, and signs it. The signature shows as valid on the Evidence tab. If anyone changes the manifest later, activation is refused.

Deploy

Platform does not deploy code. Deploy the release on the server first (push, migrate, restart), using your normal runbook. Only then activate it.

Activate

1. An operator opens the approved release and presses Activate.
2. The system checks, in order:
   • the signature is intact and the artifact hash and package digests are unchanged;
   • a verified backup exists that is newer than the environment's RPO;
   • the time is inside the environment's maintenance window;
   • the live database schema is at the release's migration head.
3. When everything passes the release becomes Active.

Worked example: backup and RPO. The environment has an RPO of 1,440 minutes (24 hours). The newest verified backup finished 1,500 minutes ago. Activation is refused: 'A verified backup inside the RPO: The newest verified backup is 1500 min old; the RPO is 1440 min.' With a backup 600 minutes old the gate passes: 'Verified backup 600 min old (RPO 1440 min).' With no verified backup at all: 'No verified backup. Take and verify one first.'

Worked example: maintenance window. The window is Friday 23:00 for 120 minutes, time zone Asia/Dubai, so it runs to Saturday 01:00.

With no start time set the gate reads 'No maintenance window is set: any time is allowed.'

After activation

• The environment's Active release is this release, and its migration head is updated.
• The previously active release on that environment becomes Retired with the reason 'Superseded by REL-0002.'
• An event platform.release_activated.v1 is raised.
• Platform > Reporting > Release readiness shows the release's packages with Traced to gate = yes, proving that what runs traces back to an approved, signed gate.

Refusals at activation

Good to know

• A release in any state can be stopped: see Send back, cancel, recover or retire a release.
• Two people reading the same release in two tabs: whoever saves second is refused with 'Somebody changed this record since you opened it. Reload and try again.'