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

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

Dan Radigan Dan Radigan

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

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

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

ヒント

Branches aren't just good for feature work. Branches can insulate the team from important architectural changes like updating frameworks, common libraries, etc.

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

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

リリース ブランチング

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

Warning:

Release branching is an important part of supporting versioned software out in the market. A single product may have several release branches (e.g., 1.1, 1.2, 2.0) to support sustaining development. Keep in mind that changes in earlier versions (i.e., 1.1) may need to be merged to later release branches (i.e., 1.2, 2.0). Check out our webinar below to learn more about managing release branches with Git.

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

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

ProTip:

Another benefit of feature flags is that the code can remain within the build but inactive while it's in development. If something goes awry when the feature is enabled, a system admin can revert the feature flag and get back to a known good state rather than have to deploy a new build.

Task Branching

At Atlassian, we focus on a branch-per-task workflow. Every organization has a natural way to break down work in individual tasks inside of an issue tracker, like Jira Software. Issues then becomes the team's central point of contact for that piece of work. Task branching, also known as issue branching, directly connects those issues with the source code. Each issue is implemented on its own branch with the issue key included in the branch name. It’s easy to see which code implements which issue: just look for the issue key in the branch name. With that level of transparency, it's easier to apply specific changes to master or any longer running legacy release branch.

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

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

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

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

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

検証、検証、検証

A version control system can only go so far in affecting the outcome of a merge. Automated testing and continuous integration are critical as well. Most CI servers can automatically put new branches under test, drastically reducing the number of "surprises" upon the final merge upstream and helping to keep the main code line stable.