Skip to content

Instantly share code, notes, and snippets.

@aneudy1702

aneudy1702/gitflow_ics_engineering.md Secret

Created May 13, 2025 13:31
Show Gist options
  • Save aneudy1702/4c55802087b67fdd878ef288424f8dd2 to your computer and use it in GitHub Desktop.
Save aneudy1702/4c55802087b67fdd878ef288424f8dd2 to your computer and use it in GitHub Desktop.
Download ZIP
Raw
gitflow_ics_engineering.md

Gitflow Branching & Deployment Strategy for Backend and Frontend

Overview

This document outlines the standardized Gitflow workflow that will be adopted by both the Backend and Frontend teams within the International Shop initiative. It also defines responsibilities across team roles and introduces the concept of a rotating Release Captain to streamline releases and improve coordination with SRE/DevOps.

Gitflow Workflow Description

Gitflow is a branching model that provides a robust framework for managing features, releases, and hotfixes across development and production environments.

Primary Branches

  • main: Production-ready code only. Tagged with version numbers.
  • develop: Integration branch for feature development. Represents the latest approved work ready for QA or pre-prod.

Supporting Branches

  • feature/<feature-name>

    • Branched off: develop
    • Purpose: Isolated development of new features.
    • Merged into: develop

  • release/<version> (e.g., release/2025-05-15)

    • Branched off: develop
    • Purpose: Final QA, bug fixes, pre-release stabilization.
    • Merged into: main and develop

  • hotfix/<hotfix-name>

    • Branched off: main
    • Purpose: Emergency fixes in production.
    • Merged into: main and develop

Backend Implementation Plan

  1. Fork the current backend repo and rename it to axp-international-shop-backend.
  2. Remove all non-international code and branches.
  3. Adopt the Gitflow workflow described above.
  4. Set up separate E2 environments with support from SRE/DevOps.

Frontend Implementation Plan

  1. Apply Gitflow workflow to the JSON content repository and all relevant frontend modules.
  2. Standardize branching and PR flow across Growth, Core, and MSE contributors.

Roles & Responsibilities

Developers

  • Create feature/ branches off develop.
  • Conduct local and E1 environment testing.
  • Raise PRs into develop.
  • Support QA during the release cycle.

QA Engineers

  • Test feature branches in E1.
  • Validate release branches in E2.
  • Raise issues against the release/ branch.
  • Collaborate with developers to verify fixes and close QA cycles.

Release Captain (Rotates Every Sprint)

  • Branches off release/<version> from develop at the start of the release window.

  • Coordinates merges from develop to release/.

  • Works with QA to ensure E2 testing is completed.

  • Collaborates with SRE/DevOps to:

    • Create the RFC for E2 deployment.
    • Coordinate approvals and timing.

  • Merges release/ into main and tags the release.

  • Merges release/ back into develop.

  • Time allocation: 20% sprint capacity to be reserved for Release Captain duties.

SRE/DevOps

  • Provide E2 environment access and deploy support.
  • Review and approve RFCs submitted by Release Captains.
  • Maintain infrastructure readiness for releases.

Benefits of this Model

  • Predictable and scalable release process.
  • Clear branch purposes reduce merge conflicts.
  • Defined ownership improves accountability.
  • Enables coordination across distributed teams (Growth, Core, MSE, DevOps).

Next Steps

  • Finalize buy-in from all teams.
  • Schedule Gitflow onboarding sessions.
  • Assign the first Release Captain for the upcoming sprint.
  • Create sample branches and walkthroughs for reference.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment