Deployment Pipelines & Releases
Snapshotting a project into a numbered release and promoting it stage by stage across environments, with approval gates and drift tracking.
How releasing works
Releasing happens at two layers, and it helps to keep them straight before you set anything up.
- Publishing a rule set is the fine-grained layer. You finalize one rule set’s changes, gated by that project’s own approval and test settings. That is covered in full on the release gate.
- Releasing a project sits above it. A project release is a snapshot of every rule set, condition, and action set in the project, taken at one moment and given a sequential release number. It bundles the rule sets you already published into one thing you can name, deploy, and talk about.
A release is immutable. It names the exact versions it includes rather than copying their content, so release 14 always means the same thing no matter how much authoring happens afterwards. Once you have a release, a deployment pipeline decides where it goes and who has to say yes along the way.
Creating a release
From Project Releases, create a release and you get a preview before anything is committed: the counts of rule sets, conditions, and action sets that will be included, and a note listing anything currently in draft that would be swept into the snapshot.
That draft note is advisory, not blocking. Drafted items are flagged so you notice them, and then they are included anyway. Read the list before you confirm — it is your last chance to spot a half-finished edit that you did not mean to ship. If the project requires passing tests, a warning is shown at this point as well.
Confirm, and the release is created with the next sequential number. From then on it is a fixed point you can promote, roll back to, or restore from.
Rolling back vs. restoring for editing
Every past release offers two actions, and they do very different things:
- Roll back creates a new release that redeploys an old release’s exact snapshot. Nothing is erased and no history is rewound. It is a forward-only action, exactly like cutting a fresh release, that happens to reuse older content. If you roll back to release 9, you get release 15 containing release 9’s snapshot.
- Restore for editing pulls an old release’s content back into authors’ current working drafts and deploys nothing. Use it when you want to resume editing from an earlier point.
Rolling back changes what is running and leaves drafts alone. Restoring for editing changes what authors are working on and leaves what is running alone. If production is broken, you want Roll back. If you reach for Restore for editing instead, the bad release keeps serving traffic while your drafts get overwritten. The screen keeps them as separate, clearly labeled actions for exactly this reason.
Deployment pipelines
A pipeline is a named, ordered list of stages. Organization admins define pipelines, and a pipeline belongs to the organization rather than to any one project. Each stage is bound to one organization environment — Development, QA, Production, and so on.
Configuring a stage means choosing three things:
- The environment the stage deploys to.
- Whether it requires approval, or deploys automatically as soon as a release is promoted to it.
- Who can approve it, when approval is required. You can allow organization admins, project members flagged as approvers, and specific named people by email address. A named approver needs no other access to the project, which is what lets you route sign-off to a compliance owner or a release manager who never authors rules.
Assign the pipeline to one or more projects and those projects start releasing through it. A project with no pipeline assigned releases straight to every environment at once, with no staged promotion — which is the right choice for a small internal project and the wrong one for anything with a production environment.
Stage order describes the intended path; it is not a hard gate. A release can be promoted directly to any stage in the pipeline, so you can push an urgent fix straight to a later stage without waiting on the earlier ones. Approval requirements still apply to whichever stage you promote to.
Promoting a release
From Project Releases, pick the stage you want to promote the current release to. The screen tells you up front whether that stage deploys immediately or will require approval first, so you know before you click whether you are shipping or asking.
A promotion that needs approval becomes a pending request, visible to everyone watching the pipeline, until an approver acts on it. Promotions are recorded in the audit log, including who requested them and who approved them.
Pipeline Dashboard
The Pipeline Dashboard is the organization-wide view: one row per project, one column per stage. Each cell shows the release number and date currently deployed to that stage, plus a drift status telling you how far that stage has fallen behind. A lock icon marks stages that require approval.
| Status | What it means |
|---|---|
| Current | The stage is running the project’s latest release. |
| Behind | A newer release exists that has not been promoted here yet. |
| Stale | The stage has been behind long enough to be worth your attention. |
| Never deployed | Nothing has ever been promoted to this stage. |
| Pending | A promotion has been requested and is waiting on approval. |
Summary counts across the top tell you how many releases are awaiting approval and how many stages are significantly behind, so you can open the dashboard and see in one glance whether anything needs a person. Projects with no pipeline assigned are listed separately rather than hidden, so an unpiped project cannot quietly escape the view.
A pending promotion shows who requested it, with Approve and Reject actions for anyone allowed to approve that stage. If the request is your own, you instead see Withdraw.
You cannot approve your own promotion request. The person who asked can withdraw the request, but somebody else has to approve it, so a single account can never move a release into a gated stage on its own.
Organization-wide release policy
An organization admin can set organization-wide floors that individual projects and pipelines cannot loosen — only be stricter than. There are five:
- Require approval before publishing, in every project.
- Require tests to pass before releasing, in every project. See Testing Rule Sets for what a passing suite means.
- Require an approval stage in every pipeline. A pipeline with no approval stage can auto-deploy straight to production with no human gate; this closes that.
- Allow expedited promotion — lets an organization admin bypass a pipeline’s approval gate for a single promotion when something genuinely cannot wait. Every use is recorded in the audit log, and it is always restricted to organization admins regardless of this setting.
- Require a different person to approve than the one who requested the promotion. The requester can still withdraw their own request either way.
These are floors, not overrides. Turning one off later does not silently loosen a project that already had the equivalent setting on — that setting simply goes back to being the project’s own choice rather than an enforced minimum. Changes to the policy itself are recorded in the audit log.
Organization-wide release policy requires the Team plan or higher. Below that, an organization cannot set these floors, but individual projects can still require approval and require passing tests on their own.