SI向けGitHub-flow改

はじめに

• SIとしてGitブランチ戦略を考えた時、何が最適か見つからなかった
  • GitHub-flowは都度リリースする形態が前提なので、SIの様にフェーズという長い期間を経てリリースするのに向かない
  • Git-flowはdevelopブランチとmainブランチの定義が曖昧、きっちり管理しないとカオスになる
  • GitLab-flow, gitworkflows...
• 運用としては単純明快なGitHub-flowがいいが、SIにおける運用や各ブランチの明確化、CICD運用を踏まえて改良して運用することにした。

概要

• mainがメインである
• タスク作業はfeature/#{issue番号}で行う
• 不具合対応はhotfix/#{issue番号}で行う
• 環境確認用ブランチ(検証: env-staging / 本番: env-production)を用意する
  • 各環境にデプロイする際に対象ブランチで上書きし、デプロイする
    上書き元と同一のブランチとしたいため、コンフリクトリスクがあるmergeやrebaseは行わない

    # STG環境の場合
    git checkout env-staging
    git reset --hard 上書き元ブランチ
    

  • 本ブランチはデプロイするためだけのテンポラリブランチであり、壊れても無くなっても問題ないものとする
  • 現在の各環境の状態となる
  • ブランチpushによるCICDを行うなら本ブランチをトリガーとする
  • 状況により環境ブランチを切る (開発: env-development等)
• ファーストリリース前後で運用方法が変わる(下図参照)
  • ファーストリリース後のmainは問題なく動作する本番環境と同じもの(受入テストを完了したもの)という扱いとする

ファーストリリース前

• 開発者にとっては基本的にGitHubFlow
• タスク作業をする際は、mainから feature/#{issue番号}を切る
  • タスク完了後、mainへマージする
• 各環境動作確認時
  • mainを環境確認ブランチ(検証: env-staging / 本番: env-production)へ上書きする

    # STG環境の場合
    git checkout env-staging
    git reset --hard master
    

  • 対象ブランチをデプロイし、動作確認する
• リリース時
  • mainをenv-staging, env-productionへ上書きし各環境にデプロイ、動作確認する

    # STG環境の場合
    git checkout env-staging
    git reset --hard master
    

ファーストリリース後

• mainよりrelease/ver{バージョン番号}を切る- タスク作業をする際は、release/ver{バージョン番号}からfeature/#{issue番号}を切る
  • タスク完了後、release/ver{バージョン番号}へマージする
• 不具合修正が生じたら、mainからhotfixを切る
  • 修正後、env-staging, env-productionへ上書きし各環境にデプロイ、動作確認する

    # STG環境の場合
    git checkout env-staging
    git reset --hard hotfix/#***
    

  • 本番の動作確認完了後、masterへマージする
  • 開発中のrelease/ver{バージョン番号}へマージする
• リリース時
  • release/ver{バージョン番号}をenv-staging, env-productionへ上書きし各環境にデプロイ、動作確認する

    # STG環境の場合
    git checkout env-staging
    git reset --hard release/ver{バージョン番号}
    

  • 本番の動作確認完了後、mainへマージする