初期スタートアップでのアジャイル開発における Git ワークフロー
初期のスタートアップで、初めてのプロダクトではウォーターフォールで開発し、その後アジャイル開発に転換していくことが多いんじゃないかと思います。
その開発スタイルに合わせて、Git ワークフローを適宜変更していけると開発しやすい環境づくりに繋がっていきます。
ウォーターフォールにおける Git ワークフローに関しては、以下の記事で紹介させていただきました。
こちらの記事では、アジャイル開発における Git ワークフローに関して 1 つの案として紹介させていただきます。
Git ブランチワークフローを定義する
ウォーターフォールでの Git ワークフローは、GitHub flow をベースにしているため、非常にシンプルでした。
Source: スタートアップでのウォーターフォール開発における Git ワークフロー
しかし上記のウォーターフォール用のフローだと、何かの機能の開発途中で一旦 main にマージしていたりして、そこから hotfix が生えた時、すぐさま hotfix のデプロイに進むことができません。
アジャイル開発においては、安定した開発と、部分的なデプロイに対応する必要があります。
そこで、以下のブランチワークフローを作成してみました。
特徴
特徴は以下の通りです。
- git-flow ベース
-
hotfixの迅速で部分的な取り込み & デプロイが可能 - Jira 等のアジャイル開発における、チケットタイプと統合
-
hotfix/*: Bug -
develop/*: Story & Task -
feature/*: Sub-Task
-
- Story や Task 単位での部分的な取り込み & デプロイに対応
- チケットタイプと統合したため、フロー自体を理解しやすい
-
stagingを今は用意しなくても、後から追加しやすい
またウォーターフォールでの Git ワークフローは、実質 queue なので別の実装に依存しているだとか、前のスプリントの開発が絶妙に残っているとかが原因で、デプロイが詰まる時があります。
そこを、スプリントが複数跨ぐ場合でも、選択的なデプロイによって、安定してプロダクトを新鮮に保つことができます。
ブランチとクラウド環境の対応
それぞれのブランチをクラウドの環境と対応付けておくと、より扱いやすくなります。
例えば、以下のような運用が考えられます。
-
mainブランチでのタグ: Production 環境 -
stagingブランチでのコミット: Staging 環境 - それ以外のブランチでのコミット: Preview 環境 (Vercel や Netlify の Preview のようなもの)
最後に
共同開発において、どのように Git ブランチワークフローを定義するのかは悩みどころだと思います。
そういった中で、こちらの記事が 1 つのアイデアになれば、幸いです。
Discussion