Table of Contents
Release Manager Guide
Branch Creation, Code Review & Manual Production Approval (GitHub)
1. Purpose of This Document
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)
2. Release Manager Responsibilities
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
3. GitHub Prerequisites (One-Time Setup)
3.1 Branch Protection Rules
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
3.2 Environment Protection (Mandatory)
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
4. Creating Branches Using GitHub Website (UI)
This section explains how a Release Manager or authorized user can create branches directly from the GitHub web interface, without using Git commands.
4.1 Creating a New Branch from an Existing Branch
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
4.2 Branch Creation Guidelines (Mandatory)
| Branch Name | Base Branch (Creation) | Primary Purpose | Allowed Promotion Flow |
| Dev | Main | Active development & feature integration | feature/* → Dev → Main |
| Main | Dev (initially created from Main only once) | Stable, release-ready code | Dev → Main → Test |
| Test | Main | Staging / UAT validation | Main → Test → Production |
| Demo | Main | Commercial / pre-sales demo features | Demo → (Approved) → Dev → Main → Test → Production |
| Production | Test | Live production system | Test → Production |
| hotfix/* | Production | Critical production fixes | hotfix/* → Production → Test → Main → Dev |
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
4.3 Creating the Demo Branch (One-Time)
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
4.4 Creating a Hotfix Branch via GitHu
Select Production branch
Open branch selector
Enter hotfix/<issue-id-or-description>
Click Create branch from Production
Immediately apply branch protection (if not inherited)
4.5 Permissions & Safety Checks
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.
5. Creating Promotion Pull Requests (GitHub UI)
4.1 Dev → Main (Release Candidate)
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
4.2 Main → Test (Staging / UAT Promotion)
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
5. Test → Production (Manual Approval Flow)
5.1 Creating the Production PR
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
5.2 Review & Approval
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.
5.3 Manual Environment Approval (Critical Step)
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.
6. Hotfix Handling (Release Manager View)
6.1 Hotfix PR to Production
Base: Production
Compare: hotfix/*
Verify emergency approval
Merge with priority
6.2 Forward Promotio
After hotfix deployment, ensure PRs are created in order:
Production → Test → Main → Dev
7. Demo Branch Oversight
Release Manager ensures: - Demo PRs are not merged into Main/Test/Production without approval - Demo deployments are manual - Demo branches are archived after decision
8. Audit & Compliance Checklist
Before Production approval, confirm: - PR approvals recorded - CI checks passed - Environment approval logged - Release notes documented
9. Virtual Release Checklist (Release Manager)
Use this checklist during every release to ensure nothing is missed. Treat it as a virtual gate.
9.1 Pre-Release Checklist (Before Test → Production PR)
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
9.2 Production Release Checklist
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
9.3 Post-Deployment Checklist
Production deployment completed successfully
Smoke tests passed
Monitoring dashboards checked
No critical alerts observed
Release marked as completed
10. GitHub UI Screenshot Mapping (Step Reference)
This section maps each release action to the exact GitHub UI location, enabling easy visual training and onboarding.
10.1 Branch Selector (Create Branch)
Path:
Repository → Code → Branch dropdown (top-left)
Used for: - Creating Demo branch from Main - Creating hotfix branches from Production
10.2 Pull Request Creation
Path:
Repository → Pull Requests → New Pull Request
Key UI Fields: - Base branch (target) - Compare branch (source) - Reviewers section - Status checks section
10.3 Pull Request Approval
Path:
Pull Request → Files changed → Review changes
Actions: - Approve - Request changes
10.4 GitH
Path:
Repository → Actions → Workflow run
Used to: - Monitor pipeline execution - Identify deployment stage
10.5 Manual Environment Approval (Production)
Path:
Actions → Workflow run → Review deployments
Actions: - Select PRODUCTION environment - Click Approve and deploy
10.6 Environment Configuration (One-Time Setup)
Path:
Repository → Settings → Environments
Used for: - Defining PROD reviewers - Enabling manual approval gates
11. Common Mistakes to Avoid
Approving Production without UAT sign-off
Bypassing PRs using admin privileges
Allowing demo code into production
Skipping forward merges after hotfix
10. Summary
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.
