====== 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/ 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.