CI/CD のブランチ管理について

DVCS におけるブランチ

ブランチ管理は、分散バージョン管理システム、特に Git への人気の高まりによってブランチがより簡単になったため、開発チームの考慮事項となりました。

分散システムでは、リポジトリの複数のコピーが存在するため、ソースオブトゥルースが複数存在することになります（ただし一般的には、チーム内でセントラルコピーまたはプライマリーコピーを指定する傾向があります）。 あなたとチームメンバーは、リポジトリにあるあなたのコピーに対する変更を並行して実施することになるため、変更を同じリポジトリの別のコピーにプッシュすることで、作業を共有しています。

Git の登場により、ブランチの作成と別のブランチのコミットのマージが非常に軽量な作業になりました。 Git では、ブランチは特定の名前でラベル付けされた単なるコミット（または一連のコミット）です。 ブランチは新機能の作業やハッキング染みた実験など、一連の変更を格納するのに最適です。

その上で、別のリポジトリにブランチをプッシュしたり、マスターなどの別のブランチとマージして、残りのコードベースと合わせたりすることで、変更を共有することができます。 また、その変更を却下するのであれば、それらを破棄することもできます。 2 つのブランチをマージする場合、Git は各ブランチのコミットの整合性をとり、他のバージョン管理システムでのマージに関わるほとんどの複雑な事項を回避します。

フィーチャーブランチ

名前からわかるように、フィーチャーブランチは、個別の機能を残りのコードベースとは別に保持するために作成されるブランチです。 作業中の機能をマスターブランチに含めないようにしておくことで、マスターをデプロイ可能な状態に維持しやすくなり、リリースブランチ（以下参照）からではなく、直接マスターからデプロイしている場合には、未完成の機能が本番にデプロイされる危険を避けることができます。 この場合でも作業内容は、ブランチを中央のリポジトリ（指定している場合）かほかの任意のリポジトリにプッシュすることで、ほかのチームメンバーと共有することができます。

フィーチャーブランチの主な欠点（ほぼトランクベースの開発の支持者からの批判）は、機能が「完成」するまで変更の統合を遅らせることで、継続的インテグレーションのメリットを損なうことにあります。 このため、マージ競合のリスクが生まれ、変更が反復的にコミットされるよりも長い時間が修正にかかってしまう、より複雑なバグが導入される可能性があります。

こういった課題は、マスター（またはリリース準備に使用するブランチ）だけでなく、フィーチャーブランチでも自動ビルドとテストを実行するように CI サーバーをセットアップすることで緩和することができます。 こうすることで、構築中のものに対するフィードバックを迅速に得られるというメリットを活かしながら、変更をマージする際に発生する課題のリスクを軽減することができます。

マージ競合を最小限に抑える方法として、フィーチャーブランチの存続期間を 1 日、最大でも 2 日に維持することが挙げられます。 また、定期的にマスターの上にブランチをリベースするか、マスターの変更をマージするというオプションもあります。 この方法を使えば、フィーチャーブランチを、マスターにコミットされれるその他すべての変更で最新の状態にすることができます。 ただし、並行する大量のフィーチャーブランチがすべてマスターへのコミットを遅らせている場合には、競合が発生するリスクを拭うことはできません。

ホットフィックスブランチ

ホットフィックスブランチはフィーチャーブランチと同じように動作しますが、完全性を得るためにも説明しておく価値があります。 ホットフィックスブランチは、バグ修正をできるだけ迅速に本番に適用することを狙いとしています。

ホットフィックスブランチは、デプロイ先に応じてマスターまたはリリースブランチから作成できます。 フィーチャーブランチと同様に、リリースブランチまたはマスターブランチにマージする前に、ホットフィックスブランチで一部の CI/CD 要素を実行することが可能です。この場合、リリース前にさらに自動テストを実施することができます。