理解してみる
GitLab Flowとは
- production、pre-production、main、featureからなるブランチ戦略である
- 主なブランチは「main」で、機能ブランチをマージし、必要に応じてプレプロダクションやプロダクションブランチを使用
開発の進め方
-
ブランチ作成
mainブランチからfeature/NAMEブランチを作成 -
開発とマージリクエスト
開発完了後、mainブランチへマージリクエストを作成 -
ステージング環境デプロイ
mainブランチをステージング環境にデプロイし動作確認 -
本番前準備
mainからpre-productionへマージリクエストを作成しテスト -
本番リリース
pre-productionからproductionへマージリクエストを作成しデプロイ
ベストプラクティス
-
featureブランチの使用
- すべての新しい作業（機能追加やバグ修正）に機能ブランチを作成し、mainブランチをクリーンに保つ
-
mainブランチのプロダクション対応
- mainブランチは常にプロダクションにデプロイ可能な状態を保つ
-
マージリクエストの必須化
- すべての変更はマージリクエストを通じてmainに統合される
-
必須のコードレビュー
- すべてのマージリクエストは少なくとも1人のチームメンバーによるレビューを受け、コード品質を維持する
-
自動テストの実施
- GitLabのCI/CDパイプラインを使用して、機能ブランチとmainブランチで自動テストを実行する
-
短期間の機能ブランチ
- 機能ブランチは短期間で作成・マージし、mainブランチとのコンフリクトを最小限に抑える
-
明確なブランチ命名
- ブランチ名に一貫した命名規則を採用し、例えばfeature/123-login-fixのようにする
-
issueとのリンク
- マージリクエストを対応するissueにリンクし、開発進捗を追跡可能にする
-
プレプロダクションブランチの活用
- 必要に応じてプレプロダクションブランチ（例：test、acceptance）を追加し、mainからのマージでテストを行う
-
ホットフィックスの管理
- 緊急のバグ修正にはmainからホットフィックスブランチを作成し、修正後すぐにmainにマージする
Githubでの実践に向けて
導入したものがあれば追記予定
設定した方が良いこと
-
ブランチ保護ルールの設定
- プルリクエストレビューを必須化
- すべてのチェックが通過することを必須化
- フォースプッシュとブランチ削除を防止
- プルリクエストの承認数を指定
-
Github Actionsを使ってCI/CDを組む
-
明確な記述とレビュアーの割り当て
- プルリクエストには詳細な説明を書き、特定のレビュアーを割り当てます。レビュアーはコードコメントや議論を通じてフィードバック1. 議論の解決
- すべての議論が解決されるまでプルリクエストをマージしないようにする
-
PR-Agnetを使ったAIコードレビュー