ソフトウェアブランチのベストプラクティス

ソフトウェア開発チームは、迅速に行動しなければなりません。予算はますます厳しくなっています。タイムラインも短くなってきています。そして、クライアントは常により多くの機能を求めてきます。もしあなたのチームが最大限の能力を発揮できるようにしたいのであれば、可能な限り効率的に仕事をする必要があります。

ソフトウェア開発チームにとって、ブランチの作成方法は生産性に関わる一要素ですが、いわゆるベストプラクティスを採用してないケースも多いようです。結果として、多くの問題や余計な労力が発生している可能性があります。この記事では、生産性を向上させる9つの方法を紹介します。

0.ブランチとは何ですか？

ブランチとは、バージョン管理システム（Version Control System: VCS）で管理されているオブジェクトのコピーのことです。VCS内のコードベースは別名トランク(幹) とも呼ばれ、そこから異なる「ブランチ(枝)」が分岐しています。これらのブランチによって、ソフトウェア開発者は、コードベースを不安定化させることなく、分離して実験することができます。大規模なプロジェクトでは、開発者や品質保証など、多くの異なる役割が必要になります。ブランチを使うことで、これらの異なる役割を満たし、並行して開発することができます。一人の人間がブランチに変更を加えても、他のチームメンバーに影響を与えることはありません。

ブランチの利点は、多くの異なる人々が同時にプロジェクトに取り組むことができるということですが、ソフトウェアのブランチ化のベストプラクティスを持っていない場合、これは大きな頭痛の種になる可能性があります。

以下では、9つのベストプラクティスを紹介します。

1.ブランチング戦略をチームに伝える

まず、どのようなブランチング戦略を採用するかを決める必要があります。ソフトウェアチームが利用するブランチング戦略で、広く採用されているものは以下の3つです。

Git Flow はおそらく最もよく知られている戦略です。2010年に策定されたこの戦略では、master が本番用ブランチであり、develop がベースブランチとして扱われるとしています。feature-*、hotfix-*、release-*など、さまざまなサポートブランチを使用することもできます。Git Flow は非常に厳格なプロセスを作成しますが、これはマージやリリースにおける心理的な不安を和らげるのに役立つかもしれません。もしあなたのQAプロセスが厳格なものであれば、Git Flowはあなたにとって最高のブランチング戦略となるかもしれません。

コインの裏返しになりますが、Git Flowは開発が本番と同等ではないため、環境間の移行が必須になります。そのため、頻繁なリリースを行う継続的デリバリー(CD)や継続的インテグレーション(CI)は、Git Flowの下では困難になる可能性があります。また、Gitの履歴が読めなくなることもしばしばあります。

GitHub Flowは、Git Flowに比べてプロセスがはるかに簡素化されており、複数の異なる環境や同時バージョンの管理を必要としない小規模なチームにとっては、優れた選択肢となります。GitHub Flowでは、まずマスターブランチから始めます。作業が必要になるたびに、新しいブランチをチェックアウトします。作業内容を確認してマージする準備ができたら、master へのプルリクエストを開くだけです。マージされてmasterにプッシュされたら、理想的にはすぐにデプロイするべきです。

このブランチ戦略はCD/CIにはより親しみやすく、1つの本番環境で1つのバージョンを運用する場合には理想的です。本番環境で複数のバージョンが必要な場合は、この分岐戦略は向いていません。同様に、GitHub Flowでは、デプロイ、リリース、イシューなどに関しての取り決めがなく、本番コードが不安定になりやすい傾向があります。

Gitlab Flowは、より新しいブランチ戦略の一つで、特にサポートが必要な環境が複数ある場合に適しています。このブランチ戦略では、masterがベースブランチとなります。新しい機能を開発する際には、masterに直接コミットせずにmasterからコードを分岐させます。このブランチ戦略は、ドリフトを最小限に抑えるのに役立ちます。この戦略を使えば、git の履歴もすっきりして読みやすくなります。CD/CI を設定することもできます。

この戦略はGitHub Flowよりも複雑で、複数の本番バージョンを維持しなければならない場合はさらに複雑になる可能性があります。

チームに適した戦略を選択したら、その戦略をチーム全体に周知させましょう。フォルダやホワイトボードなど、チームが簡単に見て思い出すことができる場所に文書化します。チームがどのくらいの頻度で、どこからコードを分岐してマージすべきかをチームに知らせるようにしてください。戦略を一度伝えたからといって、誰もがそれを覚えているわけではありません。開発サイクル全体を通して、チーム全員が同じ考えを持っていることを常に確認してください。これは簡単なことのように思えるかもしれませんが、チームの成功には絶対に必要なことです。

2.作業の依存度を把握する

ソフトウェアの分岐の実践のもう一つは、依存関係を意識することです。自分の変更が他のチームやバージョンにどのような影響を与えるかを確認し、将来のマージを可能な限り容易にするような決定をしてください。また、どのブランチにコアコンポーネントを実装するのが最適か？どこが一番便利なのか? 関係者全員にとってリスクが少ないのはどこか? これらの優先度に関する質問に対する質問の答えを予めチームで共有しておくことで、納期が迫ってきたときの無用なストレスから解放されます。

依存関係の可能性を把握して予測することも、ソフトウェア分岐の最も重要なベストプラクティスの 1 つです。

3.マージの頻度を上げる

ブランチが多いチームもあれば、少ないチームもあります。しかし、ブランチの数に関係なく、ソフトウェアのブランチングのベストプラクティスでは、頻繁にマージすることでコードのチェックアウト時間を最小限に抑えることが求められています。コードがチェックアウトされる時間が長くなればなるほど、コードは孤立していきます。そして、孤立したコードになればなるほど、それは大きな潜在的問題となります。

コードがチェックアウトされている期間が長くなると、マージがどんどん難しくなります。ソフトウェア開発のライフサイクルが長い場合でも、毎日マージすることは有用です。しかし、多くのチームはこれを行っていません。もし毎日がチームにとって多すぎるのであれば、少なくとも週1回のマージから始めましょう。そうすることで、無用なコンフリクトを防ぐことができます。Sleeek ようなツールを用いて、チームメンバーのPush やマージの状況を可視化することも生産性向上に役立ちます。

4.バージョン管理システムを賢く選ぶ

今日では、多くの異なるバージョン管理システム(VCS) があり、それぞれに長所と短所があります。いずれを選択しても、選択したVCSがチームやプロジェクトが必要とするファイル数、コントリビューター数、ビルドの要求に対応できることを確認してください。VCS の中には、プロジェクトに有益な特殊なブランチ機能を持っているものもあります。

近年ではバージョン管理システムのディファクトスタンダードとえるのはGitですが、実際にはまだまだSubversion(以下、SVN)で管理をしている現場も多いと思われます。また、Git自体にもGitそのものや、Gitをコア機能にしたプラットフォームサービス(GitLab, GitHub, Bitbucket など)があります。時間をかけて、利用可能なさまざまなオプションを検討してみてください。プロジェクトが進行してしまった後で、バージョン管理システムが必要な要件を処理できないことに気づくのは避けたいものです。

5.変更の調整

複数の異なるブランチを統合することは、熟練した開発者にとっても困難なことです。時には何日もかかることもありますし、ソフトウェア開発の知識のすべてを要求されることもあります。このため、ソフトウェア開発のベストプラクティスのもう一つは、潜在的にリスクをもたらす可能性のあるプロジェクトの要素の変更を計画し、調整することです。これは、コアライブラリのような共有要素については特に重要です。

リスクを減らし、調整を高めるのに役立つテクニックはたくさんあります。変更の影響を議論するために、特定の会議を開くことができるかもしれません。これは、チーム全体を巻き込むのに役立ちます。もう一つの選択肢は、可能性のあるすべての実装ソリューションをブレインストーミングすることです。忘れていたことや考えていなかったことを思いつくかもしれません。また、プロジェクトの共有部分を担当する独立したチームを作ることもできます。いずれにしても、変更やマージに関しては、全員が同じ意識・戦略の上にいることが、ソフトウェアブランチングで重要な部分になります。

6.開発プロセスをシンプルにする

他のほとんどのものと同様、ソフトウェアの分岐はシンプルにしておくと最もうまくいきます。このソフトウェア開発のベストプラクティスを実装するためには、ブランチは必要な期間のみ存在するようにし、無用に長生きさせないようにします。堅牢な VCS を持っている場合でも、ブランチの数を少なくすることは、長期的に役立つソフトウェアブランチのベストプラクティスの一つです。ブランチの数が多ければ多いほど、多くの問題が発生します。

同様に、マージもシンプルにしましょう。チーム内で、マージ間の時間を短縮する方法を見つけてください。チームが同時に作業するコードを分離するためにフォルダを構成することもできます。データベース内のスクリプトを継続的にアップグレードしていると、スクリプトのバージョンの競合に遭遇することがあります。これは、別々のブランチで作業している2つのチームが、同じデータベースバージョンへのスクリプトアップグレードを書いたが、データベースの変更が異なる場合に発生する可能性があります。これを防ぐには、チームごとに異なるバージョン範囲を予約するだけです。

システムが大きくなってきたら、異なるコンポーネントを別のブランチに分けて、 バイナリ形式にコンパイルしてみてください。これにより、コンポーネントのコードが一つの場所に保持され、マージを必要としないことを確認するのに役立ちます。また、コンポーネントは一度だけコンパイルされるので、ビルドはより速くなります。

どのような方法で実装するにしても、チームのために開発するにしても、シンプルであればあるほど良いです。

7.トランクの品質を守る

森の中では、いくら木の枝の手入れを頑張っていても、幹の手入れをしなければ木は生きられません。ソフトウェア開発でも同じことが言えます。開発チームは個々の枝に関心を持ちすぎて、トランク(幹) のことを忘れてしまうことがあります。すべてのコミットを高品質に保つことで、トランク(=メインライン) を守りましょう。ビルドとテストのプロセスの一部として、コードレビューとコミット前の継続的インテグレーション(CI)を使用してください。メインラインがいつでも再利用できるように最善を尽くしましょう。

8.継続的インテグレーションを促進する

アクティブなブランチごとに個別のCIプロセスを持ちましょう。これにより、各ブランチのメンテナンスが容易になり、必要に応じて変更が容易になります。CI なしでは、ブランチはマージせずに無駄に生存してしまうかもしれません。これは、マージに関連するバグの発見がプロセスの中で遅すぎることにつながり、不必要な作業やストレスの原因になります。

9.タスクが完了するまでの見積もりにマージ作業を含める

最高のアジャイルソフトウェア開発チームは、機能やプロジェクトがいつ終了したとみなされるかを決定するために、完了の定義(Difinition of Done: DoD)を使用しています。この定義には、マージ活動のための時間を含めることを忘れないでください。これは、プロジェクトを進めていく上で、潜在的な誤解を避けるのに役立ちます。 

上記のソフトウェア分岐のベストプラクティスは、あなたとあなたのチームが可能な限り最高のプロジェクトを作成するのに役立つように設計されています。すぐにでも試してみましょう！