> 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/3.0/phases/phases-overview.md).

# Overview

Phases are major milestones or stages in a release process. They provide logical grouping of activities and help organize complex release workflows across teams, tools, and environments.

### What is a Phase? <a href="#what-is-a-phase" id="what-is-a-phase"></a>

A **phase** represents a distinct stage in the release lifecycle. Within a process blueprint, phases organize the workflow into manageable, sequential or parallel stages, each containing one or more activities that contribute to a specific milestone.

Phases serve as logical containers that:

* Group related activities together by purpose or ownership
* Define major checkpoints in the delivery pipeline
* Enable clear handoffs between teams (for example, Development to QA to Operations)
* Support conditional execution based on the outcome of previous phases

Common phases include:

* **Planning & Coordination**: Gathering requirements, creating release plans, and aligning stakeholders
* **Branch Cut**: Creating release branches and preparing source code for build
* **Build**: Source code compilation, artifact generation, and packaging
* **Pre-Deployment Validation**: Testing, security scans, and quality gates
* **QA Testing**: Functional testing, regression testing, and sign-off
* **Deployment**: Deploying artifacts to target environments (staging, UAT, production)
* **Post-Deployment**: Verification, monitoring, and validation
* **Rollback**: Reversal activities if issues are detected

### Why Phases Matter <a href="#why-phases-matter" id="why-phases-matter"></a>

Phases provide structure and clarity to complex release processes:

**Organizational Alignment**: Each phase can be owned by a specific team (Development, QA, DevOps, Security), making responsibilities explicit and reducing coordination overhead.

**Progress Visibility**: Stakeholders can track which phase a release is in, understand what's been completed, and anticipate what's next.

**Gating and Control**: Phases enable approval gates and checkpoints, ensuring prerequisites are met before advancing to critical stages like production deployment.

**Reusability and Consistency**: Once modeled in a process blueprint, phases ensure every release follows the same validated workflow, reducing variability and risk.

### Phase Structure and Characteristics <a href="#phase-structure-and-characteristics" id="phase-structure-and-characteristics"></a>

Phases provide logical grouping and structure to release processes through several key components and characteristics:

#### Core Components <a href="#core-components" id="core-components"></a>

A phase consists of:

* **Name**: Descriptive identifier that clearly communicates the phase's purpose
* **Description**: Detailed explanation of what the phase accomplishes and why it exists
* **Activities**: The actual tasks within the phase (automated pipelines, manual approvals, or subprocesses)
* **Dependencies**: Defines which phases must complete before this phase can start
* **Owners**: The team or individuals responsible for executing and signing off on the phase
* **Variables**: Phase-scoped variables that activities within the phase can reference
* **Gates and Approvals**: Optional checkpoints that must be satisfied before the phase can proceed

#### Execution Flow <a href="#execution-flow" id="execution-flow"></a>

Phases typically execute in sequence, but can also run in parallel when independent:

* **Sequential**: One phase completes before the next begins (for example, Build → Test → Deploy)
* **Parallel**: Independent phases can execute concurrently (for example, Security Scan and Performance Testing)
* **Conditional**: Phases can be skipped or executed based on runtime conditions or approvals

#### Ownership and Collaboration <a href="#ownership-and-collaboration" id="ownership-and-collaboration"></a>

Each phase can have designated owners:

* **Team Ownership**: Assign phases to Development, QA, Operations, or Security teams
* **Handoffs**: Clear ownership enables smooth transitions between teams
* **Accountability**: Owners are responsible for completing phase activities and providing sign-offs

#### Status Tracking <a href="#status-tracking" id="status-tracking"></a>

Each phase has its own status, providing real-time visibility:

* **Pending**: Not yet started; waiting for dependencies or schedule
* **In Progress**: Currently executing activities within the phase
* **Completed**: Successfully finished; all activities completed
* **Failed**: Encountered errors; remediation or rollback may be required
* **Skipped**: Intentionally bypassed due to conditions or approvals
* **On Hold**: Paused; waiting for manual approvals or inputs

#### Example Phase <a href="#example-phase" id="example-phase"></a>

Here's a typical Build phase definition:

```yaml
phase:
  id: build_phase
  name: Build Phase
  description: Responsible for source code compilation and validation, artifact generation and packaging, and security scanning and compliance checks.
  owners:
    - Development Team
  depends-on: []
  activities:
    - activity:
        id: branch_cut
        name: Branch Cut
        type: manual
    - activity:
        id: run_ci_pipeline
        name: Run CI Pipeline
        type: automated
        depends-on:
          - branch_cut
    - activity:
        id: security_scan
        name: Security Scan
        type: automated
        depends-on:
          - run_ci_pipeline
```

This example shows a Build phase with three activities: a manual branch cut, followed by an automated CI pipeline, and finally a security scan.

### Common Phase Patterns <a href="#common-phase-patterns" id="common-phase-patterns"></a>

Release processes can be structured in different ways depending on organizational needs and workflow complexity.

#### Linear Phases <a href="#linear-phases" id="linear-phases"></a>

Sequential execution where each phase depends on the previous phase completing successfully:

```
Planning → Branch Cut → Build → QA Testing → Deploy to Staging → Deploy to Production → Monitoring
```

This pattern is ideal for straightforward releases where each stage must complete before the next begins.

#### Parallel Phases <a href="#parallel-phases" id="parallel-phases"></a>

Independent execution where multiple phases can run concurrently:

```
Phase A: Security Scan ─┐
                        ├→ Integration Phase → Deployment Phase
Phase B: Performance Test ─┘
```

Use this pattern when phases don't have interdependencies and can execute simultaneously to reduce overall release duration.

#### Conditional Phases <a href="#conditional-phases" id="conditional-phases"></a>

Execution based on runtime conditions, approvals, or outcomes:

```
Build Phase → QA Phase → [Approval Gate] → Production Deploy (if approved)
                                        └→ Rollback Phase (if rejected)
```

This pattern enables decision points where execution can branch based on test results, manual approvals, or other criteria.

#### Multi-Environment Phases <a href="#multi-environment-phases" id="multi-environment-phases"></a>

Sequential deployment across multiple environments:

```
Build → Deploy to DEV → Deploy to QA → Deploy to UAT → Deploy to PROD1 → Deploy to PROD2 → Deploy to PROD3
```

This pattern is common in enterprise environments where releases must be validated across multiple environments before reaching production.

### Real-World Use Case: System Release at Harness <a href="#real-world-use-case-system-release-at-harness" id="real-world-use-case-system-release-at-harness"></a>

To illustrate how phases work in practice, consider the system release process at Harness:

**Week 1: Branch Cut and QA Validation**

* **Monday**: Automated branch cut job creates release branches and deploys to QA environment
* **Tuesday - Thursday Noon**: Alpha fixes phase allows developers to submit fixes with service owner approval
* **Thursday EOD**: QA sign-off phase requires stakeholder and QA approval before proceeding

**Week 2: Production Rollout**

* **Friday Morning**: Beta rollout phase deploys to Prod 0 cluster for soak testing
* **Monday - Friday**: Beta fixes phase allows fixes with service owner approval during soak period
* **Following Monday**: Prod 1 deployment phase begins
* **Wednesday**: Prod 2 deployment phase
* **Following Monday**: Prod 3 deployment phase completes the rollout

**Hotfix Handling**: Emergency hotfix phase can be triggered between production rollouts, thoroughly investigated, and deployed with sanity testing.

This multi-week, multi-phase process demonstrates how phases provide structure, checkpoints, and clear ownership across a complex enterprise release.

### Phases and Process Blueprints <a href="#phases-and-process-blueprints" id="phases-and-process-blueprints"></a>

Phases are defined once within a **process blueprint** and then reused across multiple releases:

**Process Blueprint**: The template that defines phases, their order, and their activities. For example, a "Weekly Release Process" blueprint might define Planning, Build, QA, and Deployment phases.

**Input-Driven Flexibility**: The same blueprint can adapt to different releases by accepting different inputs. For example, this week's release might include three services, while next week's includes five—same phases, different inputs.

**Reusability**: Once a process blueprint is defined, you can link it to multiple releases, ensuring consistency and reducing the effort required to model each release.

### Phases vs. Activities <a href="#phases-vs-activities" id="phases-vs-activities"></a>

It's important to understand the distinction:

* **Phase**: A logical grouping or stage (for example, "Build Phase" or "Deployment Phase")
* **Activity**: A single unit of work within a phase (for example, "Run CI Pipeline" or "Manual QA Sign-off")

Phases provide the structure; activities provide the execution. Together, they form a complete, executable release workflow.

### Related Topics <a href="#related-topics" id="related-topics"></a>

* [Creating Phases](/release-orchestration/use-release-orchestration/release-orchestration-phases/creating-phases.md)
* [Activities Overview](/release-orchestration/use-release-orchestration/release-orchestration-activities/activities-overview.md)
* [Process Modeling](/release-orchestration/3.0/processes/process-modeling.md)