Release Manager Guide

This document is a step-by-step operational guide for the Release Manager to: - Create and manage release-related branches - Control promotion from Test → Production - Enforce code reviews and approvals using the GitHub UI - Perform manual production approvals via GitHub Environments

This guide assumes the branching policy:

Dev → Main → Test → Production (+ Demo, Hotfix)

The Release Manager is responsible for: - Ensuring correct branch promotions - Verifying CI/CD status before approvals - Enforcing reviewer and environment protections - Acting as the final gatekeeper for Production deployments

Ensure the following branches are protected: - Dev - Main - Test - Production

For each protected branch, enable: - Require Pull Request before merging - Require status checks to pass - Require approvals - Restrict who can push

Production branch (mandatory): - Minimum 2 reviewers - Only Release Managers / Senior Engineers can approve

Navigate to:

Repository → Settings → Environments

Create environments: - DEV - TEST - STAGING - PRODUCTION

For PRODUCTION environment: - Enable Required reviewers - Add Release Managers only - Enable Wait for approval before deployment

This section explains how a Release Manager or authorized user can create branches directly from the GitHub web interface, without using Git commands.

Navigate to the GitHub repository

Click on the branch selector (top-left, usually shows main or current branch)

In the branch dropdown, type the new branch name

Ensure the base branch shown is correct (e.g., Main, Test, or Production)

Click “Create branch: from ”

✔ The new branch is now created on the remote repository

Rules: - Always verify the base branch before creating a new branch - Branch names must follow the approved naming convention - Do not create long-lived branches other than Dev, Main, Test, Demo, Production

If the Demo branch does not exist:

Select Main in the branch dropdown

Type Demo in the branch name field

Click Create branch from Main

Verify branch protection rules are applied

Select Production branch

Open branch selector

Enter hotfix/<issue-id-or-description>

Click Create branch from Production

Immediately apply branch protection (if not inherited)

Before creating any branch, Release Manager must ensure: - Correct repository is selected - Correct base branch is visible - User has required permissions

Accidental branch creation from the wrong base branch must be reported and deleted immediately.

Go to GitHub Repository

Click Pull Requests → New Pull Request

Set:

Base branch: Main

Compare branch: Dev

Title:

Release: Dev to Main

Description:

Summary of changes

CI status verification

Assign required reviewers

Create Pull Request

On merge: - CI builds artifact - Auto deploy to TEST environment

Create a new Pull Request

Set:

Base: Test

Compare: Main

Title:

Promote: Main to Test

Verify:

All checks are green

No new commits added

Merge PR

On merge: - Same artifact deploys to STAGING - UAT validation begins

Navigate to Pull Requests → New Pull Request

Set:

Base: Production

Compare: Test

Title:

Release to Production

Add release notes summary

Assign Production reviewers

Create Pull Request

Before approval, Release Manager must verify: - CI pipeline is successful - Staging/UAT sign-off is complete - Change window is approved

Approve the PR in GitHub.

After PR merge:

Navigate to Actions → Workflow Run

Locate the production deployment job

Click Review deployments

Select PRODUCTION environment

Click Approve and deploy

This step manually triggers the production deployment.

Base: Production

Compare: hotfix/*

Verify emergency approval

Merge with priority

After hotfix deployment, ensure PRs are created in order:

Production → Test → Main → Dev

Release Manager ensures: - Demo PRs are not merged into Main/Test/Production without approval - Demo deployments are manual - Demo branches are archived after decision

Before Production approval, confirm: - PR approvals recorded - CI checks passed - Environment approval logged - Release notes documented

Use this checklist during every release to ensure nothing is missed. Treat it as a virtual gate.

All PRs into Dev are merged and validated

Dev → Main PR approved and merged

Main → Test PR approved and merged

All CI checks are green

UAT / Staging sign-off received

Release notes prepared

Change window approved

Test → Production PR created

Correct base (Production) and compare (Test) branches selected

Required reviewers assigned

PR approved by authorized reviewers

GitHub Actions workflow visible

Manual environment approval pending

Production deployment completed successfully

Smoke tests passed

Monitoring dashboards checked

No critical alerts observed

Release marked as completed

This section maps each release action to the exact GitHub UI location, enabling easy visual training and onboarding.

Path:

Repository → Code → Branch dropdown (top-left)

Used for: - Creating Demo branch from Main - Creating hotfix branches from Production

Path:

Repository → Pull Requests → New Pull Request

Key UI Fields: - Base branch (target) - Compare branch (source) - Reviewers section - Status checks section

Path:

Pull Request → Files changed → Review changes

Actions: - Approve - Request changes

Path:

Repository → Actions → Workflow run

Used to: - Monitor pipeline execution - Identify deployment stage

Path:

Actions → Workflow run → Review deployments

Actions: - Select PRODUCTION environment - Click Approve and deploy

Path:

Repository → Settings → Environments

Used for: - Defining PROD reviewers - Enabling manual approval gates

Approving Production without UAT sign-off

Bypassing PRs using admin privileges

Allowing demo code into production

Skipping forward merges after hotfix

This guide ensures: - Controlled and auditable releases - Clear separation of duties - Safe manual production approvals - Consistent use of GitHub as the single control plane

Release Managers must strictly follow this guide for every release.