Skip to main content

Overview

Last updated on

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 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​

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​

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

Core Components​

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​

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​

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​

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​

Here's a typical Build phase definition:

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​

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

Linear Phases​

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​

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​

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​

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​

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​

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​

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.