Skip to main content

The Release Process

Deploying an application is more than just getting code onto a server; it's a lifecycle. To ensure stability, security, and quality, every change must follow a structured path from development to production. In Infrastream, this path is defined by a ReleaseTrack manifest.

This guide explains the concept of a release track, the benefits of this approach, and how it governs the deployment of your applications.

What is a ReleaseTrack?​

A ReleaseTrack is a manifest that defines the complete, multi-stage deployment and promotion strategy for a set of applications. It is a blueprint for your CI/CD (Continuous Integration / Continuous Deployment) process, specifying the exact sequence of environments that your code must pass through before it reaches production.

You define a ReleaseTrack once for a collection of related services (grouped in an ApplicationSet), and the platform automatically enforces that every version of your code follows the prescribed path.

The Benefits of a Structured Release Process​

In the "Getting Started" guide, you created a ReleaseTrack before you created your Application. This might seem like an extra step, but it is the foundation of a secure and reliable software delivery process.

Separation of Concerns

By defining the release lifecycle in a separate manifest, we separate the "what" (the application code) from the "how" and "where" (the deployment process). This creates a clear division of responsibilities between different stakeholders.

The key benefits include:

  • Safety and Security: A ReleaseTrack ensures that no version of an application can be deployed directly to a sensitive environment like production. It must first be successfully deployed and validated in preceding environments (e.g., development, staging). This "progressive rollout" is a critical security and stability guardrail.
  • Consistency and Repeatability: Every change, whether a new feature or a small bugfix, follows the exact same automated, auditable process. This eliminates the inconsistencies and human errors that plague manual deployment processes.
  • Velocity with Confidence: Because the process is automated and has built-in safety checks, teams can release new versions more frequently and with greater confidence.

Stakeholders and Their Roles​

The release process is designed to facilitate collaboration between different teams, each with a distinct role.

  • Development Teams (The "What")

    • Who they are: The engineers building the applications.
    • Their role: Their primary responsibility is to define the Application manifest. They own the application's source code, its container image, and its specific runtime requirements (e.g., what environment variables it needs). They do not need to worry about how the application gets to production, only that it is defined correctly.

  • Product or Release Managers (The "When")

    • Who they are: The individuals responsible for the product roadmap and release schedule.
    • Their role: They are the primary owners of the ApplicationSet manifest. They decide which applications belong together as a single, releaseable product. By managing the ApplicationSet, they control which group of services will be promoted together along the release track.

  • Platform or SRE Team (The "Where" and "How")

    • Who they are: The central team responsible for the stability and governance of the cloud platform.
    • Their role: They are the owners of the ReleaseTrack manifest. They define the official, approved paths to production for the organization. By controlling the releaseStages, they ensure that every application undergoes the required sequence of testing and validation, enforcing security and quality standards.

How It Works: From Application to ReleaseTrack​

The relationship between these manifests is hierarchical and defines the entire release workflow.

  1. The Application Manifest (What): This is the most granular piece. It represents a single, deployable service. It is defined by the development team and contains all the information about that specific service.
  2. The ApplicationSet Manifest (The Grouping): Multiple Application manifests are placed as children of an ApplicationSet. This groups related services (e.g., the API, the web frontend, and a background worker for a single product) into a single, cohesive unit that should be released together. This is managed by the product owner.
  3. The ReleaseTrack Manifest (The Path): The ApplicationSet is placed as a child of a ReleaseTrack. This action subjects all applications within that set to the deployment lifecycle defined in the ReleaseTrack, which is governed by the platform team.

This structure ensures that individual development teams have the autonomy to manage their specific services, while product owners control the release packaging, and the platform team guarantees that every release follows a safe and compliant process.

The Stages of a Release​

A ReleaseTrack manifest defines up to three distinct paths, or "stages," for a release.

# Example ReleaseTrack manifest
apiVersion: lowops.manifests.v1
kind: ReleaseTrack
metadata:
  name: my-product-releasetrack
  # ... parent metadata
spec:
  # Path for validating individual PRs
  preReleaseStages:
    - environments:
        - development
  # Path for full, versioned releases
  releaseStages:
    - environments:
        - development
    - environments:
        - staging
    - environments:
        - production
  # Accelerated path for emergency fixes
  hotfixStages:
    - environments:
        - staging
    - environments:
        - production

1. Pre-Release Stages (preReleaseStages)​

  • Purpose: To validate the changes in a single developer's Pull Request (PR).
  • How it works: When a developer opens a PR for a service, the platform automatically deploys only that service to the first environment in this list (e.g., development). It then runs integration tests to ensure the change works correctly with other services in that environment. The PR cannot be merged until these checks pass. This prevents broken code from ever entering the main branch.

2. Release Stages (releaseStages)​

  • Purpose: To promote a complete, versioned set of applications to production.
  • How it works: After multiple PRs have been merged into the main branch, a release manager can trigger a "release." The platform bundles all the latest versions of the applications in the ApplicationSet into a single, versioned release package. This package is then promoted sequentially through each environment in the releaseStages list. A release cannot be promoted to the next stage (e.g., from staging to production) until it has been successfully deployed and has passed all automated and manual quality gates in the current stage.

3. Hotfix Stages (hotfixStages)​

  • Purpose: To accelerate the deployment of a critical, emergency bugfix to production.
  • How it works: In a production incident, you need a way to bypass the full release train. A hotfix follows an accelerated path. This track is typically much shorter (e.g., it might only require deployment to staging for a final sanity check before going to production), allowing you to resolve critical issues in minutes, not hours.

By understanding and using the ReleaseTrack, you are leveraging a core component of the platform that is designed to make your releases safer, faster, and more reliable.

How Stakeholders are Bound to Release Stages​

The ReleaseTrack manifest defines the path for a release, but it is the Infrastream Portal that enforces stakeholder approvals at each stage of that path.

While changes to application code and manifests are approved via the GitOps Pull Request workflow, the promotion of a release from one environment to the next (e.g., from staging to production) is a distinct action managed and audited within the Infrastream Portal.

Here’s how the roles and responsibilities map to this process:

  • preReleaseStages (e.g., development)

    • Stakeholders: Development Team.
    • Responsibility: Code correctness and quality.
    • Mechanism: This stage is typically automated. When a developer merges a Pull Request, the CI/CD pipeline automatically deploys the new version to the development environment and runs integration tests. This provides fast feedback to the development team.

  • releaseStages (e.g., staging, production)

    • Stakeholders:
      • QA/Test Engineers (for staging)
      • Product Managers (for production)
      • Security Team (for production)
    • Responsibility:
      • QA: To validate that the bundled release is stable and works as expected in a production-like environment.
      • Product: To provide the final business approval to release new features to customers.
      • Security: To perform a final check and ensure the release meets all security and compliance requirements.
    • Mechanism: To promote a release from staging to production, a Release Manager will initiate the promotion in the Infrastream Portal. The portal, aware of the ReleaseTrack, will then enforce a mandatory sign-off from the designated stakeholders (QA, Product, Security). The deployment to the next stage will not proceed until all required electronic approvals have been recorded in the portal, creating a clear and auditable governance checkpoint.

  • hotfixStages (e.g., staging -> production)

    • Stakeholders: SRE/Operations Team, Senior Leadership.
    • Responsibility: Resolving a production incident quickly and safely.
    • Mechanism: The promotion workflow in the Infrastream Portal for a hotfix is often configured with a different, accelerated set of approvers. It may require sign-off from a small, designated group of incident commanders to ensure the emergency fix is both necessary and safe to deploy without waiting for the full set of standard release approvals.

This combination of the ReleaseTrack manifest and the approval workflows in the Infrastream Portal creates a powerful, auditable, and secure release process where every stakeholder has a clearly defined role and responsibility.