> For the complete documentation index, see [llms.txt](https://developer.harness.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://developer.harness.io/release-orchestration/use-release-orchestration/release-orchestration-releases/modeling-releases.md).

# Modeling Releases

Learn how to create and model releases from processes.

Modeling releases connects a **process blueprint** to a **release instance**. You decide when the release runs, provide the inputs it needs, and confirm who owns each phase. The result is a concrete, executable release plan.

## What you will learn from this topic

* How to [create a release from a process](#create-a-release-from-a-process)
* How [release groups and cadence](#release-groups-and-cadence) control when releases execute
* How to [pre-execute a release and provide inputs](#pre-execute-a-release-and-provide-inputs)

## Before you begin

* **Release Manager access**: You need the Account Release Manager or Organization Release Manager persona. Go to [Persona-based access](/release-orchestration/use-release-orchestration/release-orchestration-releases/overview.md#persona-based-access) to review what each persona can do.
* **A process**: You need an existing process to model the release from. Go to the [Processes overview](/release-orchestration/use-release-orchestration/release-orchestration-processes/overview.md) to create one.

### Create a release from a process <a href="#create-a-release-from-a-process" id="create-a-release-from-a-process"></a>

Creating a release involves selecting a process and configuring it for a specific execution.

{% stepper %}
{% step %}

### Select a process

Select the process that defines the workflow for this release. For example:

* **Standard release process**: For regular, planned deployments.
* **Hotfix release process**: For emergency fixes with streamlined validation.
* **Feature release process**: For gradual feature rollouts.
* **System release process**: For coordinated multi-service deployments.

The process defines the phases, activities, dependencies, and approval gates that the release executes.
{% endstep %}

{% step %}

### Link the process to the release

The release inherits its structure from the process:

* All phases from the process.
* All activities within those phases.
* Dependency relationships between phases and activities.
* Approval requirements and validation gates.
* Timeout and retry configurations.

The process remains unchanged. The release is an instance that executes using that blueprint.
{% endstep %}

{% step %}

### Review and confirm owners

Phase owners are typically defined in the process, especially when you use AI-based process creation. For example:

* **Development team**: Owns Build and Integration phases.
* **QA team**: Owns Testing and Validation phases.
* **Operations team**: Owns Deployment phases.
* **Security team**: Owns Security Scanning and Compliance phases.

Confirm that ownership is appropriate for this release and adjust it if needed. For example, a hotfix release might have different owners than a standard release.
{% endstep %}

{% step %}

### Provide release metadata

Configure release-specific information:

* **Release name**: A descriptive name, for example, `payments-service-v2.1.3-production`. Go to [Use clear release naming](/release-orchestration/use-release-orchestration/release-orchestration-releases/overview.md#clear-release-naming) for naming guidance.
* **Description**: The purpose and scope of the release.
* **Tags**: Labels for filtering and reporting, for example, `production`, `security-patch`, or `service:payments`.
* **Version**: The software version being released, if applicable.
  {% endstep %}
  {% endstepper %}

### Release groups and cadence <a href="#release-groups-and-cadence" id="release-groups-and-cadence"></a>

A release can run on demand, at a scheduled time, or on a recurring cadence as part of a release group. Go to [Release execution](/release-orchestration/use-release-orchestration/release-orchestration-releases/overview.md#release-execution) for how on-demand, scheduled, and pre-executed releases start.

* **On-demand releases**: Run when a Release Manager triggers them, with no fixed schedule. Use them for hotfixes, customer-specific deployments, and features that ship when ready. Go to [Ad hoc releases](/release-orchestration/use-release-orchestration/release-orchestration-releases/adhoc-releases.md) to create one.
* **Scheduled releases**: Start automatically at a fixed date and time. Use them for planned production deployments, maintenance windows, and coordinated multi-team releases.
* **Recurring releases**: Generated automatically by a release group on a cadence. Use them for weekly, monthly, or quarterly release trains.

### Recurring releases (release groups) <a href="#recurring-releases-release-groups" id="recurring-releases-release-groups"></a>

A release group automatically generates release instances on a recurring cadence. Every generated release uses the same process structure, so the rhythm stays consistent and stakeholders know when releases occur. Each release can still have its own inputs, such as different services, versions, or configurations.

A release group has the following configuration:

| Setting    | Description                                                                 |
| ---------- | --------------------------------------------------------------------------- |
| Cadence    | How often releases are generated: Weekly, Monthly, Quarterly, or Custom.    |
| Start date | When the recurring schedule begins.                                         |
| Duration   | How long each release runs, for example, 2 days or 1 week.                  |
| Process    | The process blueprint used for every generated release.                     |
| Inputs     | Default inputs applied to every release. You can override them per release. |

For example, Harness runs a release group called "Weekly Production Release" with the following setup:

* **Cadence**: Every Thursday.
* **Duration**: 2 days, Thursday and Friday.
* **Process**: The "System Release Train" process.
* **Generated releases**: Week 15 Release, Week 16 Release, Week 17 Release, and so on.

Every recurring release appears on the release calendar, which makes conflicts and capacity easy to see. Go to [Release calendar](/release-orchestration/use-release-orchestration/release-orchestration-releases/release-calendar.md) to view and filter scheduled releases.

### Pre-execute a release and provide inputs <a href="#pre-execute-a-release-and-provide-inputs" id="pre-execute-a-release-and-provide-inputs"></a>

When you pre-execute or execute a release, you provide the concrete inputs that control how the process runs. Three features keep this input step short:

* **Input Store**: Holds multiple input sets for one process, so you can run the same process with different values, for example, one input set per production region. Go to [Input Store](/release-orchestration/use-release-orchestration/release-orchestration-inputs-variables/input-store.md) to create input sets.
* **Variable mapping**: Maps a few global variables to phase and activity variables, so you provide a value such as `releaseVersion` once and it cascades through the process. Go to [Variable mapping](/release-orchestration/use-release-orchestration/release-orchestration-inputs-variables/variables/variable-mapping.md) to configure mappings.
* **Defaults and overrides**: Pre-fills values from the process or input set, which you can override for a single execution. Go to [Default values and overrides](/release-orchestration/use-release-orchestration/release-orchestration-inputs-variables/variables/default-values-and-overrides.md) to set defaults.

### Provide inputs at execution <a href="#providing-inputs-at-execution" id="providing-inputs-at-execution"></a>

1. Select an existing input set from the Input Store, or create a new one.
2. Review the default values pre-filled from the process or input set.
3. Enter the required inputs, which are marked with an asterisk (\*).
4. Override any optional defaults that need to change for this release.
5. Review the validation results. Harness validates inputs against their expected types and constraints.
6. Confirm the inputs and start the release.

Inputs can be strings, numbers, Booleans, lists, objects, or Harness entity references such as service, environment, infrastructure, and connector. Go to the [Inputs and variables overview](/release-orchestration/use-release-orchestration/release-orchestration-inputs-variables/overview.md) for every supported type.

## Next steps <a href="#related-topics" id="related-topics"></a>

After you model a release, go to [Execute a release](/release-orchestration/use-release-orchestration/release-orchestration-execution/executing-a-release.md) to run it and monitor its progress.

* [Releases overview](/release-orchestration/use-release-orchestration/release-orchestration-releases/overview.md)
* [Release lifecycle](/release-orchestration/use-release-orchestration/release-orchestration-releases/overview.md#release-lifecycle)
* [Best practices](/release-orchestration/use-release-orchestration/release-orchestration-releases/overview.md#best-practices)
* [Release calendar](/release-orchestration/use-release-orchestration/release-orchestration-releases/release-calendar.md)
* [Inputs and variables overview](/release-orchestration/use-release-orchestration/release-orchestration-inputs-variables/overview.md)

{% @harness-feedback/feedback %}