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, connecting your own Release Runners for container-based task execution, triggering releases from external events, and building self-service workflows.
Release SaaS is hosted and managed by Digital.ai, so there is no Release server for you to deploy or configure. Digital.ai also provides and manages a cloud Release Runner for container-based plugin tasks. If you need task execution inside your own network, you can register your own Release Runner. See Release Runner.
Who This Guide Is For
This guide is for users who:
- Connect Release to CI/CD tools such as Jenkins, GitHub, GitLab, or Argo CD.
- Configure automated tasks within release pipelines.
- Set up triggers and webhooks to start releases from external events.
- Deploy and manage their own Release Runners for container-based task execution.
- Build and publish self-service workflows for application onboarding and operational tasks.
If you are calling the Release REST API programmatically or automating Release configuration as code, see Getting Started for 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, such as Jenkins or GitHub Actions, 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, such as developers and 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.
Your Release SaaS instance connects outbound to your tools. Any tool you connect to must be reachable from the Release SaaS environment. For tools that are only reachable inside your own network, run your own Release Runner and use container-based plugin tasks. See Release Runner.
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 Availability in Release SaaS
Release SaaS ships with a curated set of plugins that Digital.ai installs, maintains, and upgrades for you. There is no Plugin Manager to operate and no plugin installation step.
- Custom plugin uploads are not supported in Release SaaS. If you need a plugin that is not in the set, contact your Digital.ai representative.
- Community plugins, which are unofficial and unsupported, are not available in Release SaaS.
- Some plugins have individual task types disabled for security reasons in the SaaS environment.
Plugin Catalog
The following plugin categories are available:
- Cloud and Container Plugins covering Argo CD, AWS, Azure, Helm, Kubernetes, Terraform, and more.
- SCM Plugins covering GitHub, GitLab, and Bitbucket.
- Deployment Automation Plugins covering Kubernetes, OpenShift, Docker Compose, and Digital.ai Deploy.
- ALM/Workflow Automation Plugins covering Jira, ServiceNow, Agility, and TeamForge.
- Security and Compliance Plugins covering secrets management, policy enforcement, and security scanning.
For the complete list of available plugins and the tasks they support, see Available Plugins and Integrations.
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. For the task configuration, see Create a Jenkins Task.
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 The Ansible container plugin runs playbooks from Release pipelines.
Plugin Models
JVM-based plugins run directly on the Release server that Digital.ai manages. Task types from these plugins are available in the flow editor without any setup on your side.
Container-based plugins run as containers via Release Runner, isolated from the Release server. Digital.ai provides a managed cloud runner for these tasks, and you can register your own runner when a task needs to reach infrastructure in your own network.
Release Runner
Release Runner is a standalone application that executes container-based plugin tasks. It runs separately from the Release server and communicates back to Release over TLS 1.2 or higher.
In Release SaaS, Digital.ai provides and manages a cloud runner, so container-based plugin tasks work out of the box. Register your own runner when:
- Task execution needs to run closer to the target infrastructure, such as inside a VPC or behind a firewall.
- The target system is not reachable from the Release SaaS environment.
Your own runners appear alongside the Digital.ai-managed runner and are selected per task. For an overview of what Release Runner does and how it works, see Overview of Release Runner.
Release Runner on Docker
To run Release Runner with Docker, you need:
- A runner-specific authentication token created in Release under Settings > Release Runners.
- Outbound network access from the Docker environment to your Release SaaS URL.
With those in hand, configure the Docker command with the Release URL and token, then start the container. The Runner connects outbound to Release over TLS, so Release does not need inbound access to your network.
For full setup steps, see Run Release Runner with Docker.
Release Runner on Kubernetes
For Kubernetes-based deployments, install the runner with the xl kube install command. See Install Release Runner with xl kube, 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 |
| 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, such as poll interval, repository URL, credentials, and branch filters, and map the trigger event values to template variables. For more information, see Triggers and Create a Release Trigger.
Polling triggers require the source system to be reachable from the Release SaaS environment. For systems that are not publicly reachable, use a webhook event trigger and have the source system push the event to Release instead.
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 every endpoint you expose, because a Release SaaS endpoint is reachable from the internet.
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 |
For managing secrets used by automated task connections, see Security and Compliance Plugins.