Getting Started for Release Engineers
Release engineers design and maintain the release templates that Release Managers use to run releases in Digital.ai Release. This guide covers building templates, configuring automated tasks, organizing templates in folders, version-controlling templates with GitOps, and setting up release triggers.
This guide assumes that Digital.ai Release is already installed and that you have been granted the Create template global permission. If you need that permission, contact your Release Administrator. See Administration Guide.
Who This Guide Is For
This guide is for users who design and maintain release processes in Digital.ai Release. The role is performed by different people in different organizations: senior developers, DevOps engineers, release process owners, or automation engineers. What they have in common is responsibility for how releases are structured and standardized.
Specifically, this guide is for users who:
- Build and maintain reusable templates that standardize how releases are delivered.
- Define the phases, tasks, teams, and variables that make up a release process.
- Integrate external tools (Jenkins, Jira, Argo CD, and others) as automated steps in release pipelines.
- Organize, govern, and version-control templates across the organization.
- Define delivery patterns for coordinated, multi-team releases.
If you run releases from existing templates rather than building them, see Getting Started for Release Managers.
How Release Models a Release Process
Before building your first template, review how Digital.ai Release represents a release process. These concepts apply to every template you design.
A template is a blueprint for a release. When a Release Manager creates a release, they select a template and supply variable values for that specific run (such as the application version or target environment). The release is an instance of the template with those values applied.
Key differences between a template and a release:
- Templates do not have start or end dates. Those are set when a release is created from the template.
- Variables in templates act as placeholders for values that change between runs.
- Changes made to a template after a release has started do not affect that running release.
A template is organized into phases: sequential stages in the release process (for example: Development, QA, Deployment). Phases execute left to right. Within each phase, tasks execute top to bottom, unless configured to run in parallel.
Tasks are the individual work items in a phase. There are three types:
- Manual tasks — A team member must complete and mark these done.
- Automated tasks — The Release flow engine executes these without user intervention, using an integration plugin (for example, a Jenkins build task or a Jira ticket creation task).
- Gate tasks — Block the release from proceeding until defined conditions or cross-release dependencies are met. For more information, see Gate Tasks.
Variables are placeholders for values that change between releases, such as ${appVersion} or ${targetEnv}. They use the syntax ${variableName} and can appear in task titles, descriptions, scripts, and automated task fields.
For full definitions, see Core Concepts and the Glossary of Release Terms.
Take the Guided Tour
The first time you log in, a Welcome! Click me to get started task is waiting for you under Tasks in the sidebar. Open it to follow a guided tour of the main features of Release.
Building a Release Template
Follow these steps to create a template from scratch in Digital.ai Release.
Step 1 — Create the Template
Go to Releases > Templates in the sidebar, click New template > Create new template, enter a template name, and click Create. The template opens in the release flow editor with one default phase. For more information, see Create a Release Template.
Step 2 — Define the Phases
Phases represent the stages of the release process. Each phase is a checkpoint that a release must pass through before the next one begins.
Add a phase for each stage in your release process, such as Development, QA, and Deployment. For more information, see Add a Phase to a Release or Template.
Step 3 — Add Tasks to Phases
For each task in a phase, decide whether a person must act on it (manual), whether it can be executed automatically (automated), or whether it should block progress until a condition is met (gate). Manual tasks require a team member to complete and mark done. Automated tasks are executed by the Release flow engine using a plugin, such as a Jenkins build or a Jira ticket creation. Gate tasks hold the release at that point until defined conditions or cross-release dependencies are met. Assign each task to a team or individual user, and add a description, due date offset, or task-type-specific configuration as needed. Automated tasks that connect to external tools require a connection configured at the folder or global level. For more information, see Add Tasks to a Phase, Change a Task Type, Gate Tasks, and Connections.
Use parallel groups within a phase to model tasks that can run simultaneously, such as running automated tests across multiple environments.
Step 4 — Configure Teams
Teams are groups of users or roles assigned to a template or release. Tasks can be assigned to a team or to an individual user. Assigning tasks to teams is recommended for templates, as it ensures the correct people are notified when a release runs regardless of who is on the team at that time. By default, templates include a Release Admin team and a Template Owner team. For more information, see Configure Release Teams and Permissions.
Step 5 — Define Variables
Variables make a template reusable. They represent values that change from release to release: the application version, target environment, a ticket ID, or a flag that controls which path the release takes. Reference variables in task fields using the syntax ${variableName}. For more information, see Create Release Variables and Variable Usage Examples.
Variables can be scoped to different levels:
| Scope | Where defined | Where available |
|---|---|---|
| Template/release variable | Template Variables tab | That template and any releases created from it |
| Folder variable | Folder settings | All templates and releases in the folder |
| Global variable | Administration settings | All templates and releases across the instance |
For folder variables, see Configure Folder Variables. For global variables, see Global Variables.
Variables can also be populated from the output of an automated task. Use this to pass values between tasks in a pipeline (for example, capturing a build number from a Jenkins task and passing it to a deployment task downstream). See Map Task Output to a Variable.
Step 6 — Set Template Permissions
Template permissions control who can view, edit, and create releases from the template. Use the Teams & Permissions section to assign the following actions to teams:
- View Template — Users can see the template.
- Edit Template — Users can modify the template.
- Create Release — Users can create a release from this template.
- Edit Security — Users can modify team and permission settings.
A separate set of Release permissions controls what teams can do in releases created from this template. For more information, see Template Security.
Testing a Template
Before making a template available to Release Managers, run a test release to verify that the process works as intended. Open the template, click New release, enter a release name and test variable values, and click Create, then Start Release. For more information on creating a release, see Start a Release From a Template.
- Step through the tasks manually, using Complete, Skip, and Fail to test each path.
- Verify that variable values appear correctly in task descriptions and automated task fields.
- Verify that the correct teams receive notifications for manual tasks.
Organizing Templates in Folders
Folders group templates, releases, and workflows into a hierarchy that matches your team or project structure. Permissions set on a folder apply to all content inside it, which means you configure access at the folder level rather than on each individual template.
To move a template to a folder, use the options menu on the Templates page. To view templates within a specific folder, go to Overview > Folders in the sidebar and select the folder.
For more information, see Folders and Migrate Templates to Folders.
Version-Controlling Templates with GitOps
GitOps-enabled folder versioning stores folder contents (templates, workflows, triggers, connections, and variables) as YAML in a Git repository (GitHub, GitLab, Bitbucket, or Azure Repos). This lets you:
- Track changes to templates in version control.
- Use pull requests to review and approve template changes.
- Promote templates across environments (for example, from dev to production) through Git branches.
Template version control (the legacy feature) has been replaced by GitOps-enabled folder versioning. Use GitOps-enabled folder versioning for all new templates.
For setup instructions, see GitOps-Enabled Folder Versioning.
Viewing a Template as Code
The Code view displays a template in YAML format. Use it to inspect the complete template definition, export it for import into another Release instance, or edit the template directly as YAML.
To open the Code view, click Code under View in the left sidebar.
For more information, see Using the Code View.
Importing and Copying Templates
Import a template — Import from an exported Releasefile (YAML) or ZIP file. Go to Templates, click New template > Import template, and upload the file. See Import a Release Template.
Copy a template — On the Templates page, open the options menu for a template and select Copy. The copy is independent of the original. If the original template has release triggers, those triggers are disabled on the copy. See Release Templates.
Configuring Triggers
Triggers automatically create and start a release from a template based on a schedule or an external event (such as a webhook or a new artifact in a repository). Use triggers to start releases without manual intervention from a Release Manager.
Configure triggers from the Triggers section of the template. Select a trigger type (time-based or event-based), set the schedule or event condition, and map the trigger's output to template variables. For more information, see Understanding Triggers and Create a Release Trigger.
Triggers are disabled when you copy a template. Re-enable them manually after copying if needed.
Defining Delivery Patterns for Multi-Team Releases
If your organization coordinates multiple releases that must ship together, use Release Trains with Deliveries to define a standard delivery pattern. A delivery pattern links multiple releases through tracked items and synchronizes their progress toward a common delivery goal. Designing the pattern means defining stages and transitions, and adding delivery tasks to the participating templates so that tracked items are registered automatically when a release runs.
To get started with delivery patterns, see:
- Introduction to Delivery Patterns
- Delivery Patterns Tutorial
- Configuration & Management
- Delivery Tasks
For setting up connections and triggers that your templates depend on, coordinate with your DevOps engineer. See Getting Started for DevOps and Pipeline Engineers. For folder structure and permissions, coordinate with your Release Administrator. See Getting Started for Release Administrators.