現状(要件)

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

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

状態になっています。

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

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

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

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

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

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

などが採用しています。

つまるところ、

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

この方法の良い点は

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

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

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

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

これは、

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

この方法は

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

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

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

理由としては、

等があります。

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