フィーチャー ブランチングで大きな成果を

あるいはタスクブランチングや、リリースブランチングで。あなた次第です。

Dan Radigan Dan Radigan
トピック一覧

現在では、ほぼすべてのバージョン管理システムがブランチをサポートしています。ブランチとは、1 つの中心的コードベースから枝分かれした、独立した作業ラインです。ご利用のバージョン管理システムによって異なりますが、主要ブランチは master、メインライン、デフォルト、トランクなどと呼ばれています。開発者は自身のブランチをメインのコードラインから作成し、メインと並行する形で独立した作業を行えます。

ブランチングに悩むことはない

ブランチングを行えば、開発者チームはひとつの中心的コードベースの内部で容易に共同作業ができます。開発者がブランチを作成すると、バージョン管理システムはその時点でのコードベースのコピーを作成します。ブランチに変更を加えても、チームの他の開発者には影響を与えません。これは大変好都合です。もしすべての作業がメインコードラインで行われているとしたら、開発中のフィーチャーは不安定であるため、極めて破壊的だからです。かといって、ブランチを隔離する必要はありあせん。開発者はフィーチャーで共同作業を行う他の開発者から簡単に変更を切り離し、master から少し離れた状態で自分たちのブランチを分化させておくことができます。

ヒント

ブランチはフィーチャー作業にだけ適しているわけではありません。フレームワークや共有ライブラリの更新など、重要なアーキテクチャ面の変更から影響を受けないように、チームを保護します。

アジャイルチーム向けの 3 つのブランチング戦略

ブランチングモデルは往々にしてチーム間で異なるため、ソフトウェアコミュニティで議論のテーマとなります。大きなテーマのひとつは、master にマージして戻すにあたり、どの程度の作業をブランチに残すべきか、ということです。

リリース ブランチング

リリースブランチングとは、1 回のリリースは完全に 1 つのブランチに含まれるという概念です。つまり、開発サイクルの後半になると、リリースマネージャーは master からブランチ (例:「1.1 開発ブランチ」) を作成します。1.1 リリースへの変更すべてが二度適用される必要があります: 一度は 1.1 ブランチへ、さらにもう一度、master のコードラインへ。2 つのブランチでの作業はチームにとって負担であるとともに、2 つのブランチのマージを忘れる可能性も高くなります。多くのメンバーが同じブランチで作業をしていると、リリースブランチの管理は大掛かりで大変です。私たちは皆、ひとつのブランチにおける多くのさまざまな変更をマージする際の苦労を感じています。リリースブランチが必要な場合は、実際のリリースにできるだけ近い状態のブランチを作成してください。

警告:

市場に出ているソフトウェアのバージョンをサポートするうえで、リリースブランチングは重要です。複数のブランチ (例: 1.1、1.2、2.0 など) で 1 つの製品の開発をサポートしていることがあります。以前のバージョン (例: 1.1) で行った変更は、最近のリリースブランチ (例: 1.2、2.0) にマージする必要があることを常に念頭に置いてください。Git を使用したリリースブランチの管理については、後述のウェビナーをご覧ください。

フィーチャー ブランチング

フィーチャーブランチはよく、製品のフィーチャーを有効化・無効化する「トグル」となるフィーチャーフラッグと一緒に使用されます。これにより、フィーチャーをアクティブにする際に master にコードをデプロイし、管理することが容易になるとともに、フィーチャーをエンドユーザー向けに公開する前にコードを最初にデプロイすることも容易になります。

プロからのヒント:

フィーチャーフラグのもうひとつの利点は、コードをビルド内に残しつつ、開発中には非アクティブにできる点です。フィーチャーを有効化した際に、何かに失敗しても、システム管理者は新しいビルドをデプロイする代わりに、フィーチャーフラグを取り消し、良い状態にまで戻すことができます。

タスクブランチング

アトラシアンでは、タスク単位のブランチによるワークフローが中心となっています。Jira Software などの課題追跡アプリケーションで、各組織が作業をタスクごとに自然に振り分けることができます。すると、チームにとって課題が作業に対する接点の中心となります。タスクブランチングは課題ブランチングともいわれ、ソースコードから課題に直接つながっています。課題はそれぞれ、ブランチ名に含まれる課題キーとともにその課題のブランチで実施されます。課題キーをブランチ名から探せばよいので、どのコードがどの課題を実施しているのかわかりやくなります。このような透明性から、master や古いリリースブランチに特化した変更の適用がより簡単になります。

アジャイルはユーザーストーリーを軸として展開しているため、タスクブランチはアジャイル開発との相性が良いのも特徴です。各ユーザーストーリー (またはバグ修正) はそれぞれのブランチ内にあり、進行中の課題や、リリース準備の整った課題を把握しやすくなっています。タスクブランチングを深く掘り下げるには (あるいは課題ブランチまたは課題ごとのブランチ)、下記のウェビナーを参照してください - 最も人気のある動画です。

ブランチングの厄介な双子:マージ

私たちは皆、複数のブランチを単一の実用的なソリューションに統合することに苦労しています。従来使用されていた Subversion などの集中型バージョン管理システムでマージ作業を行うことは非常に困難でした。ですが、Git や Mercurial といった最近のバージョン管理システムでは、異なるブランチにおけるファイルのバージョンをトラッキングするためにさまざまな方法を採用しています。

マージがより簡単になり、コードベース全体でより柔軟になるにつれ、ブランチの使用期間は短くなってきています。継続的インテグレーション (CI) の一環として頻繁かつ自動的にブランチをマージする機能と、使用期間の短いブランチではより小さな変更しかなされていないという事実。Git や Mercurial を活用しているチームにとって、この狭間の「地獄のようなマージ」はもう過去のものです。

これでタスクブランチングが素晴らしいものに!

検証、検証、検証

バージョン管理システムは、マージの結果にまでしか影響を与えません。自動化されたテストと継続的インテグレーションはともに大変重要です。ほとんどの CI サーバーでは自動的に新しいブランチをテストし、最終のマージアップストリームで発生する「サプライズ」を大幅に減らし、メインコードラインを安定した状態に保つ手助けをしています。