実装とリリースが前後するのを前提としたGit運用フロー

業務で主に Ruby On Rails での開発を行っていますが、そこで得た知見や、失敗への対応などについて記します。

今回は「実装とリリースが前後する」場合に Gitの運用フローをどのようにするか、についてです。

現状(要件)

弊社は アジャイルソフトウェア開発 のうち、とりわけ エクストリーム・プログラミング(XP) を主体とした開発プロセスを採用していますが、その結果として、常に

短い開発サイクルで頻繁に「リリース」する

状態になっています。

これは「Webアプリケーション」というサービス形態からも必要なことで、より多様なチャレンジをより早く提供するために最適な方法だと考えていますが、一方、実装がやや前倒し気味に行われることもあって、「実装はしたけれども、リリースは待つ」こともよく生じます。

これに対応する方法として、一般的に考えられるのは

1. 新機能は「フラグで無効化」した上でリリースし、必要になれば「フラグを有効化」する
2. 新機能を実装したブランチのマージを遅らせる(待つ)

の 2つで、このどちらを採用するのかで「Gitの運用方法」そのものも異なってきます。

この両者を比較しながら、弊社では 2. の「マージを遅らせる」方法を採っているので、その説明も合わせて行います。

1. 新機能は「フラグで無効化」した上でリリースし、必要になれば「フラグを有効化」する方法

これは フィーチャートグル と言われる方法で、有名なところでは

• Google (Google の巨大レポジトリとブランチ無し運用)
• Flickr (第3回 ブランチvs.フラグ)

などが採用しています。

つまるところ、

1. 新機能を実装する場合には、その機能を「無効」にした上で、メインブランチにマージしてしまう
2. 利用開始までは、その機能は「無効」状態のまま、サービス全体のリリースに含めてしまう
3. 利用開始になれば、その機能を「有効」に変える

といった方法で、具体的な Gitの運用フローとしては github-flow という名称で知られています。

この方法の良い点は

• ブランチが事実上一つなので、マージ時のコンフリクトの可能性をかなり少なく出来る
• 本番機でも「一部のユーザー」に新機能の提供が出来る
• 「古い機能」と「新しい機能」の共存を前提とした実装になるので、反映時のトラブルの可能性を少なく出来る

ということになり、かなり良いことずくめな印象です。

しかし一方、逆の面としては

• 「古い機能」と「新しい機能」の共存を前提とした実装に手間がかかる
• 動作確認が「機能OFFのままリリースした時」と「機能ONにした時」と実質的に2倍になる
• アプリケーションの実装が「フラグで無効化されている部分も含む」となって見通しが悪くなる

こともあって、開発上の負担も心配になるところです。

2. 新機能を実装したブランチのマージを遅らせる(待つ)

これは フィーチャーブランチ と言われる方法で、 特に Github での Pull Request (PR) はこの「フィーチャーブランチ」での開発を前提としたものと言えます。

これは、

• 機能実装時にメインブランチから「フィーチャーブランチ」を分岐させ、そのブランチで開発を行う
• 必要に応じて適宜、インテグレーション用のブランチなどにマージする
• 最終的にリリース時に、メインブランチにマージすることによって、その新機能を利用開始状態にする

という方法で、具体的な Gitの運用フローとしては gitlab-flow という名称で知られています。

この方法は

• 「古い機能」と「新しい機能」の共存状態を考慮しなくて済む場合が多い
• 動作確認が「機能リリース時」だけに絞られる
• アプリケーションの実装内容が「使われている機能のみ」となって見通しが良くなる

といった面で開発面での負担軽減になりやすい方法ですが、一方で

• 実装に時間がかかったり、機能の利用開始時期が遅れるとマージ時にコンフリクトが発生する可能性が高い
• 「一部のユーザー」にだけ新機能の提供をする、といった方法でのサービス提供がしにくくなる
• 「古い機能」と「新しい機能」の共存を前提としない実装になるので、反映時にその部分の考慮不足があると不具合が生じる

などの面での注意を要します。

ではどちらを採用しているか

結論としては弊社は 2. の「フィーチャーブランチ」での開発を主体としています。

理由としては、

1. 開発を早く廻すためには「ある程度のリスクが生じても、開発の負荷を減らす」ほうがメリットが多いと判断していること
2. 特に「利用開始が遅れることによるコンフリクト発生の可能性」については、出来る限りの対処を行っていること(内容については次回に記します)
3. 必要に応じて「フィーチャートグル」も取り入れて、一部テストや利用開始の遅延に対処するようにしていること(同上)

等があります。

実際にどのような工夫をして「フィーチャーブランチ」での開発を進めやすくしているかについてや、具体的に gitlab-flow をどのように用いているかについては、次回に記載します。