Getting Started for DevOps and Pipeline Engineers
DevOps and pipeline engineers use Digital.ai Release to connect the CI/CD toolchain into release orchestration. This guide covers configuring connections to external tools, setting up automated tasks in release pipelines, deploying Release Runner for container-based task execution, triggering releases from external events, and building self-service workflows.
This guide assumes that Digital.ai Release is already installed. If you need to deploy or configure the Release server or Release Runner infrastructure, see the Installation Guide.
Who This Guide Is For
This guide is for users who:
- Connect Release to CI/CD tools such as Jenkins, GitHub Actions, GitLab, or Argo CD.
- Configure automated tasks within release pipelines.
- Set up triggers and webhooks to start releases from external events.
- Deploy and manage Release Runners for container-based task execution.
- Build and publish self-service workflows for application onboarding and operational tasks.
If you are building custom plugins or calling the Release REST API programmatically, see Getting Started for Plugin and Integration Developers.
How Release Fits Into a CI/CD Pipeline
Release coordinates the tools in your delivery pipeline rather than replacing them. A typical integration pattern works as follows:
- A CI system (Jenkins, GitHub Actions, or similar) builds and tests an artifact.
- A trigger or webhook notifies Release that the build is complete.
- Release starts a release pipeline, calling downstream tools (deployment, testing, monitoring) as automated tasks.
- Release tracks overall progress, enforces gates, and notifies the right people at each stage.
Connections, plugins, triggers, and webhooks are the four building blocks for this integration.
Self-Service Workflows
Workflows are reusable, step-by-step automation sequences that users can run on demand from the workflows catalog. They cover operational tasks that teams run repeatedly, such as onboarding an application to Argo CD or Flux CD, without requiring the user to understand the underlying tools.
As a DevOps engineer, your role is to build and publish workflows that other teams (developers, release managers) can run self-service.
Built-In Workflow Examples
- Install Argo CD
- Set up an Argo CD application
- Update an application in Argo CD
- Set up a Flux CD deployment server
Manage Workflows
- To view available workflows, navigate to the Workflows Catalog.
- To create or edit a workflow, go to Manage Workflows.
- Workflows follow the same template-based structure as releases: phases, tasks, variables, and teams.
For more information, see Workflows Overview, Workflows Catalog, and Manage Workflows.
Connecting Release to External Tools
A connection stores the credentials and endpoint configuration for an external tool. Automated tasks in release pipelines reference connections by name. Credentials are not embedded in the task directly.
Connections can be configured at two scopes:
| Scope | Where defined | Available to |
|---|---|---|
| Global | Configuration > Connections | All folders and templates across the instance |
| Folder | Overview > Folders > [folder] > Connections | Templates and releases within that folder only |
Use folder-scoped connections when different teams use different instances of the same tool (for example, separate Jenkins servers per team).
Create connections under Configuration > Connections for global scope, or within a specific folder for folder scope. Select the connection type, fill in the endpoint URL and credentials, then test and save. For more information, see Connections.
Adding Automation to Release Pipelines
Plugins extend Release with new automated task types. When a template includes an automated task from a plugin, Release executes it using the plugin's integration logic: calling the external tool's API, running a script, or triggering a job.
Plugin installation is managed by your Release Administrator. See Plugin Management.
Where Plugins Come From
- Bundled plugins ship with Release by default and require no separate installation.
- Official plugins are published by Digital.ai and installed from the Browse tab in the Plugin Manager.
- Custom plugins are uploaded manually for a tool with no official plugin. See Plugin Management.
- Community plugins are unofficial and unsupported, maintained outside Digital.ai and typically hosted on GitHub under xebialabs-community. They are not available from the Plugin Manager's Browse tab.
If no existing plugin covers your tool, build one using the Python SDK or Go SDK. See Getting Started for Plugin and Integration Developers.
Plugin Catalog
The following plugin categories are available:
- Cloud and Container Plugins — Argo CD, AWS, Azure, Helm, Kubernetes, Terraform, Jenkins (container), GitLab (container), and more.
- CI/CD Plugins — Ansible, Ansible Automation Controller, Airflow.
- SCM Plugins — GitHub, GitLab, Bitbucket.
- Deployment Automation Plugins — Kubernetes, OpenShift, Docker Compose, Digital.ai Deploy.
- ALM/Workflow Automation Plugins — Jira, ServiceNow, Agility, TeamForge.
- Incident/Monitoring Plugins — OpsGenie, Dynatrace.
- Quality Testing Plugins — Digital.ai Continuous Testing, SonarQube, SonarCloud.
Key CI/CD Integrations
Jenkins The Jenkins plugin lets Release trigger Jenkins jobs and wait for their results as part of a release pipeline. A corresponding Jenkins plugin also lets Jenkins notify Release of build status. Both JVM-based and container-based variants are available.
GitHub Actions The GitHub Actions integration lets GitHub Actions workflows trigger Release pipelines or report status back to Release.
Argo CD The Argo CD container plugin lets Release deploy and sync Argo CD applications as automated tasks. For a full end-to-end example, see Continuous Delivery with Release and Argo CD.
Kubernetes The Kubernetes container plugin lets Release apply manifests, check rollout status, and interact with Kubernetes clusters directly from pipeline tasks.
Terraform
The Terraform container plugin lets Release run terraform plan and terraform apply as pipeline steps.
Ansible Both a JVM-based Ansible plugin and an Ansible Automation Controller plugin are available for running playbooks and job templates from Release pipelines.
Plugin Models
JVM-based plugins run directly on the Release server JVM. Task types from these plugins are available in the flow editor once the plugin is installed.
Container-based plugins run as containers via Release Runner, isolated from the Release server. They support Python and Go, and can be deployed and upgraded independently of the Release server.
Container-based plugins require at least one Release Runner to be deployed and registered. See Release Runner below.
Release Runner
Release Runner is a standalone application that executes container-based plugin tasks. It runs separately from the Release server (inside Docker or on a Kubernetes cluster) and communicates back to Release over TLS 1.2 or higher.
Use Release Runner when:
- You are using any container-based plugin.
- You need task execution to run closer to the target infrastructure, such as inside a VPC or behind a firewall.
Release Runner on Docker
To run Release Runner with Docker, you need:
- A running Release instance with a URL reachable from the Docker environment.
- A runner-specific authentication token created in Release under Settings > Release Runners.
With those in hand, configure the Docker command with the Release URL and token, then start the container. The Runner connects to Release over TLS, so Release does not need inbound access to the Docker network.
For full setup steps, see Run Release Runner with Docker.
Release Runner on Kubernetes
For Kubernetes-based deployments, configure the Release Runner through the operator. See Configure and Register Release Runners and Configuration Parameters for Release Runner.
Starting Releases Automatically
Triggers and webhooks let external systems start Release pipelines without manual intervention.
Triggers
Triggers automatically create and start a release from a template when a specified condition is met.
| Type | Use case |
|---|---|
| Time-based | Start a release on a recurring schedule (nightly, weekly) |
| Git | Start a release when a commit, tag, or branch change is detected |
| Nexus | Start a release when a new artifact is published to Nexus |
| JFrog | Start a release when a new artifact is published to Artifactory |
| Subversion | Start a release on an SVN commit |
| Webhook event | Start a release in response to an inbound HTTP request |
Configure triggers from the Triggers section of the template. Select a trigger type, set the parameters (poll interval, repository URL, credentials, branch filters, and so on), and map the trigger event values to template variables. For more information, see Triggers and Create a Release Trigger.
Triggers are disabled when you copy a template. Re-enable them manually on the copy.
Custom HTTP Endpoints
Other systems can reach the Release server over HTTP to push an event, instead of Release polling them. This reduces load on both Release and the external system. For example, you can configure GitHub to send a webhook event to Release when a commit occurs.
There are three components:
- HTTP Endpoint — An endpoint configured in Release that listens for inbound HTTP GET or POST requests from an external system.
- Webhook Event Trigger — Subscribes to an HTTP endpoint and creates a release when a matching event arrives.
- Webhook Event Task — Subscribes to an HTTP endpoint and acts as a gate task, transitioning to Completed when the matching event arrives.
To configure a webhook, create an HTTP endpoint connection in Release, point the external system to that endpoint URL, then create a Webhook Event Trigger on the template and map the event payload to template variables.
For more information, see Webhooks Overview, HTTP Endpoints for Webhooks, and Webhook Event Triggers.
HTTP endpoints for webhooks are not protected by standard Release authentication. Configure custom authentication on the endpoint if it is accessible from untrusted networks.
Cloud-Native Integration Patterns
The following end-to-end guides cover common DevOps integration scenarios with Release:
| Scenario | Guide |
|---|---|
| Deploy to Amazon EKS | Release and Deploy to AWS EKS |
| GitOps CD with Argo CD | Continuous Delivery with Release and Argo CD |
| Progressive delivery with Argo Rollouts | Progressive Delivery using Argo Rollouts |
| Policy enforcement with OPA | Application Security using OPA |
| Blue/Green deployments | Blue/Green Deployment |
| Canary deployments | Canary Deployment |
| Deployment rollbacks | Deployment Rollbacks |
Backstage Integration
If your organization uses Backstage as an internal developer portal, the Release Plugin for Backstage lets teams view and interact with Release pipelines from within Backstage.
For managing secrets used by automated task connections, see Security and Compliance Plugins.