> 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/overview.md).
# Overview
Learn about releases and how they represent planned deployments.
Releases represent software delivery executed using a process. A release is the instantiation of a process blueprint with concrete inputs, connecting the abstract workflow to real-world deployment activities across services, environments, and teams.
## What you will learn from this topic
* How a [release relates to a process](#what-is-a-release)
* Why [releases matter](#why-releases-matter) for visibility, governance, and traceability
* How releases can be [executed](#release-execution): scheduled, pre-executed, or on demand
* What [components make up a release](#release-components)
* How [release status](#release-status) and the [release lifecycle](#release-lifecycle) work
* How [release creation levels](#release-creation-levels) and retention policies apply
## What is a release?
A **release** is an instance of a process: a runnable execution of a predefined workflow with specific inputs and configurations. While a process defines *how* releases should be executed (the phases, activities, and dependencies), a release defines *what* is being delivered and *when* it should happen.
Think of it this way: a process is the blueprint, like "Weekly Production Release Process," while a release is one execution of that blueprint, such as "Week 15 Production Release - Services A, B, C."
A release combines the following:
* **Process:** The template that defines the structure, phases, and activities.
* **Inputs:** The services, versions, environments, and configurations that make this release unique.
* **Variables:** Release-specific values that let the same process behave differently in a different context.
* **Schedule:** When the release runs: immediately, at a scheduled time, or as part of a recurring cadence.
* **Status:** Where the release stands, from not started through running to completed or failed.
* **Ownership:** The team or individuals responsible for managing the release.
* **Audit trail:** The complete history of execution, approvals, changes, and outcomes.
## Why releases matter
Releases bridge the gap between abstract process definitions and concrete software delivery. They provide the following benefits:
* **End-to-end visibility:** A release is the single source of truth for what is being deployed, where it is going, and what stage it is in. Stakeholders track progress in real time instead of chasing updates across tools and chat channels.
* **Governance and auditability:** Every execution records who approved what, when activities ran, what inputs were provided, and what the outcomes were. This satisfies regulatory requirements and simplifies compliance audits.
* **Cross-team coordination:** Development, QA, Security, and Operations work within the same release context, so handoffs are explicit and everyone knows what their team needs to do next.
* **Predictability:** Modeling releases on a calendar with defined cadences lets teams plan ahead, avoid conflicts, and coordinate dependencies across services.
* **Traceability:** A release links commits, builds, artifacts, tests, approvals, and deployments into one record, so questions like "What is deployed in production?" have an immediate answer.
## Release execution
Releases are created from processes and can be executed in several ways to suit different release strategies.
### Scheduled execution
Releases can be configured to execute at a specific date and time based on business cadence. This includes weekly releases, such as every Thursday at 2:00 PM for production deployments; monthly releases, such as the first Monday of each month, for system-wide updates; or custom schedules that match your organizational rhythm.
Scheduled execution enables predictable release windows, better resource planning, and reduced conflicts across teams.
### Pre-execution
You can execute a release before its scheduled time when circumstances require it. This is useful for early deployments when you need to push critical features or fixes ahead of schedule, for testing and validation, where you run through the release process in advance to identify issues, or for coordination with external events such as customer announcements or partner integrations.
Pre-execution preserves the same audit trail, approvals, and governance as scheduled execution, so you do not lose compliance benefits when you need to move faster.
### On-demand execution
Releases can be triggered immediately when needed, without waiting for a scheduled time. This works well for hotfix releases that address emergency deployments for critical production issues, feature releases where you deploy when a feature is ready rather than being tied to a fixed schedule, or customer-specific releases where you deploy to specific customer environments on request.
### Process integration
Once releases are connected to processes, activities execute automatically based on the process definition. All stakeholders see the same real-time view of progress, every action, approval, and change is tracked for compliance, and required checkpoints, approvals, and validations are enforced.
The release calendar provides a consolidated view of all releases across the organization, helping teams coordinate, avoid conflicts, and plan capacity.
## Release types and use cases
Different release types serve different purposes depending on your deployment needs and urgency.
### Standard release
Standard releases are regular, planned deployments following a defined cadence, such as a weekly production release every Thursday. These releases follow the full process, including all validation phases, ensuring thorough testing and approval before deployment. They are ideal for routine feature deployments and scheduled updates where you have time to follow the full process.
### Hotfix release
Hotfix releases handle emergency deployments for critical issues, such as deploying a security patch immediately. These releases use a streamlined process with only essential validation, allowing you to move quickly while still maintaining necessary safety checks. They are used for production incidents and critical security vulnerabilities where speed is essential, but some validation is still required.
### Feature release
Feature releases focus on deploying specific features or capabilities, such as enabling a new feature flag for gradual rollout. These releases include feature-specific validation and monitoring to ensure the new capability works correctly. They are used for new product capabilities, A/B testing, and progressive delivery, where you want to roll out features incrementally.
### System release
System releases coordinate deployment across multiple services and environments, such as a quarterly platform upgrade affecting 50+ services. These releases involve multi-phase deployment over days or weeks, allowing you to roll out changes gradually and validate at each stage. They are used for major version upgrades, platform-wide changes, and infrastructure migrations where coordination across many components is essential.
## Release components
A release consists of several interconnected components that work together to execute software delivery.
### Process
The process template defines the release's structure: the phases the release progresses through, such as Build, Test, Deploy, and Monitor, and the activities within each phase, such as automated pipelines, manual approvals, or subprocesses.
The process also defines the execution order through dependencies, the checkpoints and approvals required before critical phases, and the teams or individuals responsible for each phase. The process remains unchanged across releases. It is the reusable blueprint that ensures consistency.
### Inputs
Concrete values provided when creating or executing the release make each release unique:
* **Services:** Which services are included, such as payment-service or user-service.
* **Versions:** The artifact versions, build numbers, or commit SHAs to deploy.
* **Environments:** Target environments such as DEV, QA, UAT, PROD1, PROD2, or PROD3.
* **Configuration values:** Environment-specific settings, feature flag states, and resource limits.
* **Metadata:** Release notes, ticket IDs, customer names, and rollback plans.
The same process executed with different inputs produces different releases. Go to [Input Store](/release-orchestration/use-release-orchestration/release-orchestration-inputs-variables/input-store.md) to manage reusable input sets for a process.
### Variables
Release-specific variable values control runtime behavior at different scopes:
* **Global variables:** Available across the entire release, such as `releaseVersion` or `targetRegion`.
* **Phase variables:** Scoped to one phase, such as `qaEnvironment` for the Testing phase.
* **Activity variables:** Scoped to one activity, such as `deploymentTimeout` for a deployment activity.
* **Computed values:** Derived from other variables or activity outputs, such as an artifact URL from build output.
Go to [Variable mapping](/release-orchestration/use-release-orchestration/release-orchestration-inputs-variables/variables/variable-mapping.md) to pass values from global variables down to phases and activities.
### Schedule
The schedule determines when and how the release should execute. Immediate execution starts the release now, while scheduled execution runs at a specific date and time, such as Friday, April 15, 2025, at 2:00 PM UTC.
Recurring releases are generated automatically on a set cadence through release groups, such as every Thursday for 2 days. The release calendar shows all of them so teams can see when releases are planned and avoid conflicts.
### Ownership and collaboration
Clear ownership designates who is responsible for the release and its phases:
* **Release Manager:** Coordinates the overall release.
* **Phase owners:** Teams responsible for specific phases, such as Development for Build, QA for Testing, or Operations for Deployment.
* **Activity owners:** Individuals responsible for specific activities, such as the approvers for production sign-off.
* **Stakeholders:** Interested parties who receive notifications and can view progress.
## Release status
Releases have statuses that reflect their execution state, providing immediate visibility into where the release stands.
### Status lifecycle
A release moves through the following statuses:
| Status | Meaning |
| ------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **NotStarted** | Created, but execution has not begun. The release is waiting for its scheduled time or a manual trigger, and inputs may still be under review. |
| **Running** | At least one phase is executing. Activities are processed according to their dependencies, and some may be waiting for approvals or manual input. |
| **On Hold** | Paused, waiting for manual intervention such as an approval, sign-off, or additional input. The owners are notified, and execution resumes once they respond. |
| **Success** | All required phases and critical activities completed successfully. Optional activities may have been skipped or ignored. |
| **Failed** | At least one critical phase or activity failed, and recovery actions such as retries or fix-and-continue did not succeed. Rollback may be required. |
| **PartialSuccess** | Some phases succeeded while others failed or were skipped. Non-critical failures were ignored so the release could progress, and the gaps are documented for follow-up. |
| **Aborted** | Intentionally stopped before completion, because of external factors, a higher-priority issue, or a decision to defer. Aborted releases can be restarted or rescheduled. |
### Status visibility
Status is visible at three levels: the overall release, each phase (such as Build, Test, or Deploy), and each activity within a phase.
This hierarchy makes diagnosis quick. If a release fails, drill down to the phase that failed, then to the activity that caused it.
## Release creation levels
Releases can be created at different organizational levels to match your structure and governance requirements.
### Account-level releases
Account-level releases are recommended for organizations with a smaller number of sub-organizations and similar release requirements. These releases apply across the entire account and all organizations, making them ideal for company-wide releases, platform updates, and shared infrastructure deployments.
They provide centralized control and coordination, and all organizations see and participate in the same release. If releases are created at the account level, do not also create organization-level releases, to avoid conflicts.
For example, a quarterly platform release affecting all business units might require coordinated deployment across 20+ organizations.
### Organization-level releases
Organization-level releases work well for organizations with independent release requirements. These releases apply only within a specific organization, supporting organization-specific features, independent product lines, and regional deployments.
They provide organizational autonomy while still adhering to account-level policies. Releases are only visible within the organization, and each organization can define its own release cadence and processes.
For example, an e-commerce organization might have a weekly feature release that is independent of other organizations' release schedules.
### Persona-based access
Release management supports the following personas:
* **Account Release Manager:** Creates, edits, and views releases at the account level, manages the account-wide release calendar, and ensures compliance with organizational policies.
* **Organization Release Manager:** Creates, edits, and views releases at the organization level, manages organization-specific release schedules, and coordinates with account-level releases.
* **Viewer:** Views the release calendar and release configurations, and receives notifications for releases they are involved in, but cannot create or edit releases.
## Release activation and draft state
Releases progress through states before they become active.
### Draft state
When a release is in draft state, it is being configured but not yet finalized. All release properties can be modified, including the process, inputs, schedule, and ownership. Activities are not monitored or executed in this state. This state is useful for planning, review, and approval before committing to the release execution.
### Activation
A release becomes active when all required inputs and configurations are provided and finalized. For scheduled releases, activation happens when the scheduled start time arrives. For non-scheduled releases, an Account or Organization Release Manager must explicitly activate it.
Once activated, the release starts tracking activities and execution. Status updates become visible to stakeholders, audit trails are generated for compliance, and notifications are sent to owners alerting them that the release has begun.
### Auto-activation
If a release has a configured timeline, it automatically activates when the timeline becomes effective. Scheduled releases start at their designated times without anyone having to activate them.
## Release lifecycle
The following diagram shows how a release moves from draft to a final state:
```mermaid
stateDiagram-v2
[*] --> Draft
Draft --> Scheduled: Finalize and set schedule
Draft --> Running: Activate now (on demand)
Draft --> [*]: Delete
Scheduled --> Running: Start time reached, or pre-execute
Running --> OnHold: Manual activity needs input
OnHold --> Running: Input provided
Running --> Completed: All phases finish
Running --> Aborted: Manual abort
OnHold --> Aborted: Manual abort
Completed --> [*]
Aborted --> [*]
```
Each stage allows different actions:
| Stage | Actions available | What to expect |
| ------------- | ----------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **Draft** | Edit, delete, finalize, activate | You can change the process, inputs, schedule, and owners freely. The release is not tracked or monitored, no activities run, and it does not appear in active execution views. |
| **Scheduled** | Pre-execute, edit (limited), cancel | The release waits for its start time and appears on the release calendar. Inputs and configuration are locked. |
| **Running** | Monitor, pause (limited scenarios), abort | At least one phase is executing and activities run according to their dependencies. Status updates in real time, and owners are notified of manual activities or failures. |
| **On hold** | Provide inputs, approve, reject, abort | A manual activity is waiting for an approval, sign-off, or extra input. Execution resumes once the input is provided, and the assigned owners are notified. |
| **Completed** | View history, generate reports, archive | Every phase and activity has reached a final state, and the full audit trail and execution history are kept. |
A completed release ends in **Success**, **Failed**, or **PartialSuccess**. A critical failure that recovery cannot fix ends the release as **Failed**, not **Aborted**; **Aborted** means someone stopped it on purpose.
While a release runs, individual activities can pause for input or sign-off, failed activities can be retried, ignored, or fixed without restarting the entire release, and phases run sequentially or in parallel based on their dependencies.
## Release retention and archiving
Retention keeps the system performant and aligned with data retention policies.
### Retention policy
Releases older than one year are automatically archived by default. Releases that are still active are retained even if they are more than one year old, so active work is not interrupted.
Retention aligns with pipeline and dashboard retention policies, providing consistent data management across the platform.
### Archiving rules
Archived releases are no longer visible in the active release calendar but are retained for audit and historical analysis, and you can still reach them through reporting and audit interfaces. If an archived release is deleted, all associated activities and execution history are also deleted.
### Deletion restrictions
You cannot delete a release in any of the following cases:
* **Active:** The release is Running or On Hold.
* **Within retention:** The release has tracked execution data and is within the retention period.
* **Referenced:** Other releases or reports refer to it.
These restrictions prevent accidental deletion of important release data. Draft releases can be deleted at any time before activation, since they have not started execution.
## Example: system release at Harness
To illustrate how releases work in practice, consider the system release process used at Harness. This example shows how a complex, multi-week release unfolds with clear phases and ownership.
The release creation begins with a release group set to a weekly cadence that starts every Monday. The release is linked to the "System Release Train" process, and all necessary inputs are configured, including services, environments, and build configurations.
During Week 1, the release focuses on QA validation. On Monday, the release activates, and an automated branch cut job creates release branches and deploys to QA. From Tuesday through Thursday at noon, the alpha fixes phase allows approved fixes from developers. On Thursday end of day, the QA sign-off phase requires stakeholder and QA approval before proceeding.
Week 2 handles the production rollout. On Friday morning, the beta rollout phase deploys to the Prod 0 cluster for soak testing. From Monday through Friday, the beta fixes phase allows approved fixes to be applied during the soak period. The following Monday, the Prod 1 deployment phase begins, followed by the Prod 2 deployment on Wednesday, and the Prod 3 deployment phase the following Monday completes the rollout.
If critical issues are discovered during this process, a separate hotfix release is created. This uses a streamlined "Hotfix Process" with only essential validation, is deployed between production rollout phases with sanity testing, and is fully tracked and auditable despite the expedited timeline.
This example shows multi-week, multi-phase execution with clear ownership at each phase: Development handles alpha fixes, QA provides sign-off, and Operations manages production deployments. A hotfix runs alongside without disrupting the main release, and the audit trail covers the entire lifecycle.
## Best practices
### Use clear release naming
Use descriptive, consistent release names that include version, purpose, and target environment to eliminate ambiguity. Good examples include "Payment Service v2.1.3 - Production Deployment," "Week 15 System Release - April 2025," or "Hotfix: Security Patch CVE-2025-1234."
Avoid generic names like "Release 1" or "Prod Deploy" that do not provide enough context for stakeholders to understand what the release contains.
### Minimize input complexity
Keep inputs simple and focused to reduce the burden on users and minimize errors. Use variable mapping so that users provide only essential inputs at execution time, with sensible defaults for non-critical variables.
Use the Input Store to manage multiple input sets for the same process, and document what each input controls and when it is needed so users understand what they are providing.
### Use recurring cadence
Use release groups for predictable, recurring releases, such as weekly production releases on Thursdays, monthly platform updates on the first Monday, or quarterly security patches. This reduces manual effort, improves predictability, and enables better planning by automating release creation on schedule.
### Plan processes per release type
Model a different process for each release type instead of forcing every release through one:
* **Standard process:** Full validation, all environments, complete testing.
* **Hotfix process:** Streamlined validation, expedited approvals, direct to production.
* **Feature process:** Feature flag enablement, gradual rollout, A/B testing.
* **Rollback process:** Reversal activities, validation, and rollback testing.
### Establish clear ownership
Assign explicit owners for each release and phase to ensure accountability and streamline coordination. The Release Manager coordinates the overall release; phase owners handle their respective stages; and activity owners provide approvals and sign-offs. Document ownership in the release configuration so everyone knows who is responsible for what.
### Document release context
Use the release description to record the purpose and scope of the release, the services and environments it touches, known risks, the rollback plan, and who needs to be involved. Link the release to related tickets, commits or pull requests, runbooks, and monitoring dashboards so participants can reach supporting information quickly.
### Review before execution
Before starting a release, confirm that the phases and activities suit this release, all inputs are provided and validated, owners are aware and available, the timing does not clash with other releases on the calendar, and dependent services or systems are ready.
### Plan for failure scenarios
Design releases with failure handling in mind to ensure releases can recover from problems gracefully. Define rollback phases for critical deployments, specify which activities can be retried or ignored, and establish escalation paths for blocked releases.
Document recovery procedures for common failure scenarios so the team can recover quickly when issues arise.
### Use the release calendar
Use the calendar for coordination across teams and releases. Visualize upcoming releases to identify conflicts before they happen, and coordinate with other teams' releases to avoid resource contention.
Plan capacity and resource allocation based on scheduled releases, and communicate release windows to stakeholders so everyone knows when changes are happening.
### Maintain audit trails
Ensure complete traceability by capturing all approvals with timestamps and approver names, and documenting any deviations from the standard process. Record reasons for retries, ignores, or aborts, and link to external tickets, commits, and incidents.
This audit trail supports compliance requirements and helps teams learn from past releases.
### Set up release notifications
Release Orchestration supports notifications for key release events, such as a release starting, completing, failing, or waiting for input. Go to [Notifications](/release-orchestration/use-release-orchestration/notifications.md) to send these alerts to Slack.
## Next steps
Go to [Modeling releases](/release-orchestration/use-release-orchestration/release-orchestration-releases/modeling-releases.md) to create your first release from a process, or to [Execute a release](/release-orchestration/use-release-orchestration/release-orchestration-execution/executing-a-release.md) to run one.
* [Modeling releases](/release-orchestration/use-release-orchestration/release-orchestration-releases/modeling-releases.md)
* [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)
* [Execute a release](/release-orchestration/use-release-orchestration/release-orchestration-execution/executing-a-release.md)
{% @harness-feedback/feedback %}