Core Concepts
Digital.ai Release is a release orchestration platform. It lets teams plan, track, and execute releases from a single location, giving every stakeholder — developers, QA engineers, release managers, and operations teams — a consistent view of release status.
This topic covers the core concepts you will encounter when working with Digital.ai Release.
Core Release Concepts
A release represents a set of activities carried out over a defined time period by people and automated systems. Each release has a start date, an end date, an owner, and a flow of phases and tasks. Releases move through a life cycle: planned → active → completed (or aborted).
A release is divided into phases, which represent sequential stages such as Development, QA, and Deployment. Phases must be completed in order. Each phase contains one or more tasks.
Tasks are the individual units of work in a phase. A task is either manual (requires a person to act) or automated (executed by the Release engine without human intervention). Specialised task types include:
- Gate tasks — block the release from proceeding until defined conditions or cross-release dependencies are met.
- User Input tasks — prompt a user for information, which is stored as a variable for use in later tasks.
- Script tasks — execute a Jython or Groovy script.
- Custom tasks — contributed by plugins to integrate with third-party tools.
The release flow is the ordered sequence of phases and tasks. When a release starts, the Release engine activates each task in sequence: executing automated tasks directly and sending notifications for manual tasks.
Each release has a release owner who receives notifications when a task fails, when a task is overdue, or when a team member flags that they need help.
Templates and Reuse
A template is a reusable blueprint from which releases are created. Templates define the phase and task structure, team assignments, and variables. They are never executed directly. Key differences from releases: templates have no start or end dates, and variables act as placeholders for values that are supplied at release creation time.
Variables are named placeholders that store values used in a release or template. Three scopes are available:
- Release variables — scoped to a single template or release.
- Folder variables — available to all templates and releases within a specific folder.
- Global variables — available to all templates and releases in the system.
Folders organise templates, releases, workflows, and dashboards in a hierarchy. Permissions and connections defined on a folder are inherited by everything inside it.
GitOps-enabled folder versioning links a folder to a Git repository, placing templates and folder configuration under version control. Changes are reviewed as pull requests and the Git history provides a full audit trail.
Users, Roles, Teams, and Permissions
Teams are groups of users assigned a role — for example, Development, QA, Operations, or Release Management. Teams are defined primarily at the folder level, where they apply to all templates and releases within that folder. Teams can also be set directly on a template or release. Permissions are assigned to teams at folder, template, or release level.
Users, roles, and permissions follow a role-based access control (RBAC) model. Permissions are granted to teams on folders, templates, and releases. The Authenticated Users role gives all logged-in users access to the self-service workflow catalog.
Connections
Connections store the credentials and endpoint configuration that Release uses to communicate with external systems such as Jenkins, Jira, ServiceNow, Argo CD, and AWS. Every automated task that interacts with a third-party tool uses a connection.
Connections are scoped to either global or folder level:
- Global connections — available to all folders, templates, triggers, and releases.
- Folder-level connections — available only within the folder and its subfolders.
A template or release inherits global connections plus all connections defined in its folder ancestry. For example, a template in Folder A1 (a subfolder of Folder A) has access to global connections, connections in Folder A, and connections in Folder A1. Triggers follow the same inheritance rules.
Supported authentication protocols include username/password, OAuth, OIDC, API keys, certificate-based authentication, and SSH keys. Only administrators can configure global connections. Folder-level connections can be delegated to users with the Edit Connections folder permission.
Triggers and Automation
Triggers start releases automatically in response to external events. Supported trigger types:
- Git triggers — poll a Git repository and fire on a new commit.
- SVN triggers — poll a Subversion repository for new commits.
- Nexus triggers — monitor a Sonatype Nexus repository for new artifact versions.
- Webhooks — receive an incoming HTTP request and start a release in response.
- Cron triggers — start releases on a schedule defined by a cron expression.
Scheduled scripts poll an external system at a defined interval within a custom task — for example, to wait until a condition is met before the task completes.
Plugins add integrations with third-party tools. They contribute custom task types, triggers, and dashboard tiles. Plugins use one of two execution models:
- JVM-based plugins run inside the Release server process.
- Container-based plugins run in isolated containers managed by a Release Runner.
Release Runner and Container-based Plugins
A Release Runner is a standalone process deployed as a container (on Kubernetes or Docker) that executes container-based plugin tasks on behalf of the Release server. Running tasks outside the Release server process provides plugin isolation, independent scalability, and the ability to place execution close to target infrastructure.
Key characteristics:
- Execution isolation — a failing plugin container does not affect the Release server or other plugins.
- Independent scaling — Runners scale independently of the Release server.
- Network proximity — Runners can be deployed inside a private network or close to the infrastructure they target.
- Queued delivery — if the Release server is temporarily unreachable, the Runner queues results and delivers them when connectivity resumes.
- Python and Go support — container-based plugins can be written in Python or Go, as well as Jython.
Runner Capabilities are labels assigned to a Runner. A container-based task declares which capability labels it requires (for example, prod or aws), and Release routes the task only to matching Runners. Multiple Runners can be registered to one Release instance for redundancy and load distribution.
Runners are installed separately using the XL CLI or a self-service workflow, and are registered with the Release server using a personal access token.
Self-Service Workflows
Self-service workflows are step-by-step guided processes for a single user to complete a utility task — such as onboarding an application, provisioning a cloud resource, or rotating a secret. Unlike releases, which coordinate work across multiple people over hours or days, a workflow is intended for one user and typically completes in minutes.
| Release | Workflow | |
|---|---|---|
| Scope | Multi-person, cross-team | Single user |
| Duration | Hours to days | Minutes to hours |
| Purpose | Orchestrate a software release | Perform a utility or operational task |
The workflow catalog lists available workflows. Built-in workflows cover Argo CD and Flux CD setup, cloud application onboarding (AWS, Azure, GCP), secrets management, and security scanning. Teams can also create custom workflows.
Applications and Environments
An application represents a software service or component that is built and deployed by a team. An environment is the deployment target — for example, Development, Staging, or Production. Linking an environment to an application lets Release track where each application is currently deployed and enforce deployment controls.
Environment availability and environment scheduling control when deployments to a given environment are permitted — for example, restricting production deployments to specific time windows.
The Live Deployments page shows the current deployment state of all applications across all environments, including hybrid and multi-cloud targets.
Release Trains and Deliveries
Deliveries coordinate multiple releases into a release train. A delivery tracks items — features, fixes, or components — as they move through each contributing release. Delivery patterns define the repeatable structure used to assemble a delivery.
Gate tasks act as checkpoints within a release. In addition to local conditions (such as checkboxes), a gate task can depend on a milestone in another release, blocking progress until that milestone is reached. This is the main mechanism for synchronising work across releases in a train.
Dashboards and Reporting
The home page dashboard shows active releases, recent workflows, templates, and applications. It is customisable with tiles — configurable components that display release status, task counts, and integration data.
Custom dashboards let teams build additional views with tiles tailored to their reporting needs. The reports dashboard provides built-in reports across all releases.
The Gantt chart shows the planned and actual timeline of phases and tasks within a release.
The release value stream report shows where delays and failures occur across completed and aborted releases.
All events in a release — task completions, status changes, comments, and reassignments — are recorded in an activity log with the user and timestamp.
Analytics and DORA metrics dashboards report on release performance and engineering metrics.
Release uses machine learning on historical data to estimate task duration and predict failure risk before a release starts. See Risk Awareness.
Administration
A blackout period is a configured time window during which specified tasks or deployments are not permitted — for example, during a production change freeze.
Release archiving moves completed releases to a separate archive database. Archived releases remain searchable. Export hooks run a script at archive time — for example, to write release data to an external database for long-term reporting. The archive can be purged to reclaim storage.
Risk profiles combine task failure rates, overdue items, and missing assignees into a risk score for a release.
Plugin management covers installing, removing, and updating plugins via the Plugin Manager UI or CLI. Air-gapped environments are supported. In cluster deployments, plugins are synchronised automatically across nodes.
DevOps as Code allows templates, releases, folders, variables, and connections to be defined as YAML files and provisioned via the XL CLI. Blueprints are reusable YAML structures for infrastructure provisioning and application deployment.
The REST API exposes Release functionality over HTTP: create and start releases, complete tasks, manage variables, and more. A Jython API is also available within script tasks. The Release MCP Server (beta) provides a Model Context Protocol interface that AI agents can use to manage releases, templates, tasks, and variables.
Release supports OIDC, LDAP, and personal access tokens for authentication. SAML is supported indirectly — by integrating Release with the Digital.ai Identity Service, which acts as an OIDC bridge to a SAML-compliant IDP. Personal access tokens are used for machine-to-machine access — for example, to register a Release Runner or call the REST API from a script.
Quick Reference
| Concept | Description | Learn More |
|---|---|---|
| Release | A time-boxed set of activities tracked from planned to complete. | Release Life Cycle |
| Phase | A sequential stage within a release, containing one or more tasks. | Phases and Tasks |
| Task | A unit of work — manual, automated, gate, script, or custom. | Task Types |
| Release Flow | The ordered sequence of phases and tasks that the Release engine executes. | Release Flow Editor |
| Release Owner | The user responsible for a release, who receives failure and escalation notifications. | Configure Release Properties |
| Template | A reusable blueprint for creating releases. | Create a Template |
| Variable | A named placeholder for a value, scoped to a release, folder, or globally. | Variables |
| Folder | A hierarchical container for templates and releases with inherited permissions and connections. | Manage Folders |
| Team | A group of users assigned a role, defined at folder, template, or release level. | Teams and Permissions |
| Trigger | An event-driven rule that starts a release automatically. | Understanding Triggers |
| Gate Task | A task that blocks release progress until conditions or cross-release dependencies are met. | Task Types |
| Workflow | A self-service guided process for a single user to complete a utility task. | Workflows Overview |
| Delivery | A coordinated set of releases forming a release train. | Delivery Patterns |
| Dashboard | A configurable view of release status and metrics, built from tiles. | Custom Dashboards |
| Activity Log | A record of all events in a release, with user and timestamp. | Release History |
| Plugin | An add-on that contributes task types, triggers, and tiles (JVM-based or container-based). | Integrations Guide |
| Release Runner | A containerised agent that executes container-based plugin tasks outside the Release server. | Release Runner Overview |
| Runner Capabilities | Labels on a Runner that determine which tasks are routed to it. | Runner Capabilities |
| Container Plugin | A plugin whose tasks run in isolated containers, written in Python or Go. | Release Runner Overview |
| Risk Profile | A risk score derived from task failure rates, overdue tasks, and missing assignees. | Risk Awareness |
| GitOps Versioning | Version control of folder configuration via a linked Git repository. | GitOps Folder Versioning |
| Connections | Stored credentials and endpoints for external systems, inherited through the folder hierarchy. | Connections |
| Blackout Period | A configured time window during which specified tasks or deployments are blocked. | Understanding Triggers |
| Application | A software service or component tracked through its deployment lifecycle. | Applications and Environments |
| Environment | A deployment target linked to one or more applications. | Environments |
| Live Deployments | A view showing the current deployment state across all applications and environments. | Live Deployments |
| Plugin Management | Installation, removal, and synchronisation of plugins across the Release server. | Plugin Manager |
| REST API | HTTP interface for automating Release from external systems and scripts. | API Docs |
| DevOps as Code | YAML-based definition and provisioning of Release objects via the XL CLI. | DevOps as Code |
| Personal Access Token | A credential for machine-to-machine authentication with Release. | Personal Access Tokens |
| MCP Server | A Model Context Protocol interface for AI-driven release management (beta). | Release MCP Server |
| Archive | A separate database of completed releases, retained for search and reporting. | Release Archiving |
| Blueprint | A reusable YAML structure for infrastructure provisioning and deployment automation. | Blueprints |