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

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

現在では、ほぼすべてのバージョン管理システムがブランチ ― ひとつの中心的コードベースから枝分かれした、独立した作業ライン ― をサポートしています。ご利用のバージョン管理システムによって異なりますが、主要ブランチは 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.2、2.0) にマージする必要があることを常に念頭に置いてください。Git を使用したリリースブランチの管理については、後述のウェビナーをご覧ください。

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

より柔軟なブランチングモデルを模索している多くのアジャイルチームは、リリース ブランチングからフィーチャー ブランチングへとすでに移行しています。フィーチャー ブランチ モデルは、特定のフィーチャーに対するすべての変更をブランチ内に維持します。フィ―チャーが自動テストにより十分にテストおよび検証されると、ブランチは master にマージされます。

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

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

タスク ブランチング

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

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

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

わたしたちは皆、複数のブランチを一つの実用的なソリューションに統合するために苦労しています。今までは、Subversion などの集中型バージョン管理システムで大変なマージ作業を行っていました。ですが、Git や Mercurial などの最近のバージョン管理システムでは、異なるブランチにおけるライブ状態のバージョンファイルをトラッキングできる、異なる方法を採用しています。

Git を使えば、マージは簡単 – ブランチング ワークフローを最大限に活用できる

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

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

検証、検証、検証

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