今回は、どこのプロジェクトでも必ずといって良いほど活用することになる「ブランチ」を解説します。ブランチはプロジェクトに参加するメンバーが必ず備えておくべき知識と言っても過言では無いでしょう。
ソフトウェア開発の相反する要求をどのようにクリアするか
ソフトウェアの開発を行っていると、「今のソースコード一式を確保」しつつ、「別の目的を達成するための開発」を同時並行的に行わなければならない場面が出てきます。たとえば、以下のような例です。
- あなたの担当するソフトウェアは現在、バージョン1.0がリリースされています。
- バージョン1.0 には改修すべきバグ発見されており、
これらを改修したバージョン1.1 をリリースをするようユーザーから求められています。
- さらに、バージョン1.1のリリースと同時期に、
バージョン1.0に新機能を追加したバージョン2.0 をリリースするよう求められています。
- バージョン2.0 では、バージョン1.0 で発見されたバグも改修されている必要があります。
このような場合にどのように対応しますか? まずは、状況を整理してみましょう。バージョン1.1 は、バージョン1.0のバグ改修版。バージョン2.0は、バージョン1.0に機能を追加しつつ、バージョン1.0のバグ改修も取り込んでいます。よって、バージョン1.1 に追加機能を盛り込んだものとも言えるでしょう。
これを図で表現すると以下のようになります。

上の手順で品質面のニーズは満たせそうですが、一点問題があります。それは、スケジュールですね。先ほどの要件では、「ほぼ同時期に」バージョン1.1とバージョン2.0をリリースするよう求められています。
では、今度はリリース時期のニーズを満たせるように考えてみましょう。単純に表現すると以下のようになります。

つまり、バージョン1.1とバージョン2.0を同時並行で進めることで、ほぼ同時期に両方の機能を実現するわけです。ただし、この方法を採る場合には注意すべき点がいくつかあります。まず、それぞれの開発過程で互いに影響を及ぼさないよう環境を分離しておく必要があります。また、それぞれの開発が完了した時点で、バージョン1.0のバグ改修内容をバージョン2.0に反映をさせる必要があります。
このように、ソフトウェア開発の場では、品質とリリース時期に代表されるように、一見相反するニーズへの対応を求められることがあります。これらに柔軟に対応するには、ソフトウェア構成管理を十分実践できている前提で、ブランチという概念が有効です。
この記事は参考になりましたか?
- SEが知っておきたいソフトウェア構成管理きほんのき連載記事一覧
-
- プロジェクトメンバーが必ず押さえておくべきマナー~ブランチ戦略の基本
- ソフトウェア構成管理のカギを握るベースラインとビルド管理
- 作業管理とプロセス制御でプロセス駆動ソフトウェア構成管理を実践
- この記事の著者
-
長沢 智治(ナガサワ トモハル)
ソフトウェア開発業務改善のプリンシパル コンサルタント、ソリューション アーキテクトとして多くの多種多様なソフトウェア開発の現場のお手伝いを経験。現在は、マイクロソフトのエバンジェリストとして、特にチーム開発、開発プロセスやプラクティスの訴求を行うべく活動中。 ・ブログ「長沢智治のライフサイクルブログ」
...※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です
この記事は参考になりましたか?
この記事をシェア