Deployment Pipelines: Promote Rule Changes Like Code

Software teams stopped editing production in place a long time ago. Changes get built once, promoted through staged environments, and gated by someone other than the author, and a dashboard tells you what is running where. Business rules have mostly escaped that discipline: they get edited live, in the environment where they run, with far weaker controls, and often nobody can say with certainty which version of which rule is in production right now.

Deployment pipelines and project releases bring that discipline to AI Rule Engine. You cut a numbered release of an entire project, promote it stage by stage through your environments with approval gates where you want them, and watch the whole organization from one board.

From one rule set to a whole project

There are now two layers of release, and the distinction is the whole idea.

Publishing a single rule set is the fine-grained act, and it already exists. It is gated by the release test gate: the full test suite has to pass green against the exact candidate you are publishing, not against some earlier run that happened to be green.

A project release is the layer above it. It is a snapshot of every ruleset, condition, and action set in a project, taken at one moment and given a sequential release number. It is immutable, and it names the exact versions included rather than copying their content, so a release is a precise manifest of what shipped rather than a duplicate of it. Release 12 means the same thing next quarter that it means today.

When you create one, you get a preview first: counts of everything that will be included, plus an advisory flag if anything in the project is currently in draft, since drafted items get swept into the snapshot. That flag is information, not a blocker. If the project requires passing tests, you are warned about that here too, before you commit to a number.

Rollback and restore are not the same thing

These two are easy to confuse and the consequences of confusing them are real, so they are kept clearly separate in the UI.

Roll back creates a brand new release that redeploys an old release’s exact snapshot. Nothing is erased and no history is rewound. It is forward-only, just reusing old content. If you are on release 15 and roll back to release 9’s content, you get a new release 16 that happens to match release 9. The trail still reads 1 through 16, and anyone auditing later can see exactly what happened and when.

Restore for editing pulls an old release’s content back into your authors’ working drafts and deploys nothing at all. Use it when you want to resume authoring from an earlier point without touching production. One action changes what is running; the other changes what you are editing. Neither one quietly does the other’s job.

Pipelines: who approves what, and where it goes

An organization admin defines a pipeline as a named, ordered list of stages. Each stage is bound to one organization environment and carries an approval mode: deploy automatically, or require approval first.

For a stage that requires approval, the admin picks who can grant it, from three sources that combine:

• organization admins
• project members flagged as approvers
• specific named people by email, who need no other access to the project at all

That third source matters more than it sounds. A compliance officer or a risk lead can be the required approver on your production stage without being given edit rights to a single rule.

Stage order is advisory rather than a hard gate. A release can be promoted directly to any stage in the pipeline, which is what you want at 2am when an urgent fix has to reach production without waiting for the earlier stages to clear. The order documents the intended path; it does not trap you on it.

A pipeline is assigned to one or more projects. A project with no pipeline behaves the way things worked before: a release goes out to every environment at once.

Promoting is done from the Project Releases screen. You pick a stage, and the UI tells you up front whether that stage deploys immediately or has to wait on approval, so you are never guessing whether you just shipped something.

One dashboard, every project

The Pipeline Dashboard is the org-wide view: one row per project that has a pipeline, one column per stage. Each cell shows the release number and date currently deployed there, along with a drift status of current, behind, stale, never deployed, or pending. A lock icon marks stages that require approval, so you can read the shape of a team’s governance at a glance.

Pending promotions appear in place with the name of whoever requested them. If you are allowed to approve that stage, you get Approve and Reject. If it is your own request, you get Withdraw and nothing else. That is the four-eyes control: you cannot approve your own promotion request. You can pull it back, but someone else has to let it through.

Summary counts across the top show how many releases are awaiting approval and how many stages have fallen significantly behind. Projects with no pipeline are listed separately rather than hidden, because the ones nobody has set up yet are exactly the ones worth seeing.

Setting the floor for the whole organization

On the Team plan and above, an organization admin can set an organization-wide release policy: floors that every project and every pipeline must meet, so no single project can quietly turn off the safety rails.

The controls are:

• require approval before publishing, everywhere
• require tests to pass, everywhere
• require an approval stage in every pipeline, which closes the gap where a pipeline of all-automatic stages can deploy straight to production with no human gate
• allow expedited bypass-approval promotion for emergencies, always restricted to organization admins, with every single use audited
• enforce four-eyes across the organization

Project settings can be stricter than the floor, never looser. And turning a control off at the org level later does not retroactively loosen a project that already had the equivalent setting on. It simply goes back to being that project’s own choice.

Open a project, cut a release, and promote it.

Visit RuleEngine.ai to try it.

The AI Rule Engine Team