CI/CD Pipelines

CI/CD Pipelines automate the movement of business rules between DecisionRules Spaces and environments. They use the Management API and DecisionRules Pipeline Tools to export, compare, back up, and import rule projects as part of an existing DevOps release process.

No. DecisionRules provides the Management API and pipeline utilities that perform the rule operations. Your existing CI/CD platform orchestrates when those operations run, where artifacts are stored, and whether an approval is required.

You need a source Space, a destination Space, their DecisionRules environment URLs, and a Management API key for each Space. The official Pipeline Tools run with Node.js and can be added to a standard CI/CD runner. A protected Git repository or object store is recommended for release artifacts and backups.

The tools are provider-neutral scripts. DecisionRules provides documented examples for Azure DevOps, AWS CodeBuild, and Google Cloud Build. The same approach can be used with GitHub Actions, Bitbucket Pipelines, Jenkins, OpenShift Pipelines, and other platforms capable of running Node.js commands.

Yes. The Pipeline Tools support DecisionRules Public Cloud, Regional Cloud, Private Managed Cloud, and on-premise deployments. Each source and destination is identified by its environment URL and Space-specific Management API key.

The standard Pipeline Tools export and import an entire Space, including its rule resources and folder structure. For more selective workflows, the Management API also exposes operations for individual rules, versions, Rule Flows, and folders, allowing teams to build a pipeline around the scope they need.

Yes. Export the source and destination Spaces and run the comparison step before import. The Pipeline Tools can create a JSON comparison artifact that gives reviewers an overview of the rule changes between the two environments.

Yes. Approval is configured in your CI/CD platform. For example, the documented Azure DevOps workflow separates comparison and migration into different stages and requires approval before the migration stage can update the destination Space.

Yes. Your CI/CD platform controls the trigger. A pipeline can be started manually, scheduled, or connected to a repository event such as a commit or merge, depending on your release policy.

Publishing is a separate lifecycle decision. The pipeline moves the exported rule project; it should not be treated as automatic approval of unfinished business logic. Define the expected rule statuses in your release process and verify them before production traffic is directed to the imported rules.

Yes. The documented full-Space workflow backs up the destination, clears it, and then imports the selected source artifact. Because this is a replacement operation, the destination backup, environment comparison, and approval gate are important safeguards. A customized Management API workflow can use a narrower deployment scope when full replacement is not appropriate.

Yes. The pipeline belongs to your DevOps workflow, so validation steps can be added before approval or after import. The official Pipeline Tools focus on exporting, comparing, clearing, and importing Spaces; teams can extend the pipeline with their own policy checks or post-deployment Solver API smoke tests.

Before deployment, the pipeline saves the current Production Space as a backup file. If the new release needs to be reversed, a recovery pipeline clears the affected Space and imports the selected backup. Production is then returned to the state captured before deployment.

No. Rule Versioning manages numbered iterations of an individual rule inside a Space. Pipeline recovery restores a saved snapshot of a Space or environment. Use Rule Versioning for the lifecycle of one rule and CI/CD backups for environment-level deployment recovery.

Store backups outside the destination Space in a protected Git repository, your CI/CD artifact store, or object storage such as Amazon S3 or Google Cloud Storage. Apply the retention and access policies required by your organization.

Store every Management API key in the secret store of your CI/CD platform. Use a separate key for each Space, limit who can run production deployments, and never commit keys to the repository or print them in pipeline logs.

Yes. Separate Spaces create a clear boundary between work in progress and production-ready logic. Many teams use a Development, Testing or Staging, and Production progression, but the exact number of environments depends on their review and compliance requirements.

Export and back up the destination, compare it with the source, review unexpected changes, require the appropriate approval, and retain the deployed artifact. After import, run the validation or smoke tests defined by your release process.

Keep the recovery pipeline separate from the normal deployment pipeline, protect access to it, and test it before it is needed. Make sure the team knows which artifact represents the last known-good production state and how to select it during recovery.