Windows Info 第57回

ビルドやブランチなど、Windows 10に使われる用語を整理する

プロジェクト管理されるソフトウェア開発

　Windows 10の文書やマイクロソフトのブログでは、「ビルド」や「ブランチ」などの聞き慣れない用語が使われている。これらは、ソフトウェア開発関係の用語だ。今回は、こうした用語を整理しておく。

　現在のソフトウェア開発では、ソースコードを世代ごとに記録／管理していく「ソースコード管理システム」を使うのが一般的で、ソフトウェアの状態などは、ソースコード管理という視点で表現されることが多い。

　ソースコード管理システムとは、ソフトウェアを構成するソースコードや関連のファイルを世代ごとに記録し、いつでも前の状態に戻したり、複数の変更を並行して行うことなどを可能にするシステムだ。

　ソフトウェアは単純にソースコードだけでできているわけではなく、たとえば、付属の文書（オンラインソフトでReadMeという名前のファイルを見たことはないだろうか？　こうしたものがリリースに必要なファイルとなる）や、インストーラーの制御スクリプトなど、多数の「ファイル」から構成されている。こうしたファイルを管理するのが「ソースコード管理システム」だ。

　開発者は、変更したソースコードでテストを行ない、きちんと動作することを確認した「正しい状態」のソースコードを「ソースコード管理システム」に登録する。これを「チェックイン」などという。1つのソースコードについてみると、過去のチェックインが存在し、一本の線のようになる。

　ソースコード管理システムでは、1つのソフトウェア製品を「プロジェクト」として、関連するファイルをすべて管理する。大規模なソフトウェアでは、1つのプロジェクトが複数のサブプロジェクトから構成されることもある。

　おそらくWindowsでは、全体が1つのプロジェクトになっているが、たとえばメモ帳や電卓といった標準付属のアプリなどはサブプロジェクトとして管理されている。また、Internet ExplorerやEdgeといったソフトウェアもサブプロジェクトになるが、この規模になると、さらにサブプロジェクトに分かれている可能性もある。

　こうした「プロジェクト」に属するソースコードなどを使い、配布可能な状態を作ることを「ビルド」という。もちろんサブプロジェクトは個々にビルドが行なわれ、全体のビルドを行うときにビルドされたサブプロジェクトが組み込まれていく。

ソフトウェアを構成するソースコードやファイルなどは、対応するプログラムや製品ごとに「プロジェクト」として管理されている。大規模なソフトウェアでは、1つのプロジェクトは複数のサブプロジェクトに分かれている。プロジェクト単位でソフトウェアを配布可能な状態に組み上げることを「ビルド」と言う

　ビルドを行うとき、ビルド番号が割り当てられ、自動的にソフトウェアに組み込まれていく。一般にこうしたビルド番号には、単調増加するような数字や、日付などから作られた数字を使う。Windows 10のビルド番号は、TH2までは単調増加する番号が使われてた。

複数のビルドが並行して開発されている状態で
必要となる処理がブランチ

　しかし、ソフトウェアの開発では、現在バージョンのメンテナンス（バグの修正など）を行ないつつ、次世代バージョンの開発を進める。このような場合、ソースコードは現在のバージョンのバグ修正のために変更され、次世代の新機能を組み込むために修正されることがある。このような場合、ソースコードのコピーを作り、一方を現行バージョンの修正用に、もう1つを次世代用にしてそれぞれで修正を行う。こうした処理を「ブランチ」という。

現行版のメンテナンスと次世代版の開発を並行して行うような場合には、ソースコードを「ブランチ」させて、個別に作業を行なう。一旦ブランチして分かれたソースコードなどの変更を統合することを「マージ」という。Windows10では、TH1とTH2は別のブランチとして開発されるだけでなく、実際の利用でも「Current Branch(CB)」（最新のアップグレード状態のもの）と、アップグレードを延期している「カレントブランチフォービジネス(CBB)」の2つの「ブランチ」に分かれる

　ブランチは、このようにバグ修正と新機能組み込みなどのようにまったく違う変更を同一のソースコードに対して行なわねばならない場合に利用する。ブランチを行なうと、プロジェクトから複数のビルドを作ることができるようになる。

　マイクロソフトほどの規模の会社であれば、TH2でバグ修正を行うチームと、次世代のアップグレードとなるRS1の開発を行うチームが別にあり、それぞれがブランチさせたソースコードで開発を行っていると思われる。RS1プレビュー版のビルド番号が「11082」となっているのは、TH2までの「10xxx」というビルド番号とは独立してビルド番号を割り振ることができるようにしたいからだ（逆に言えば、RS1の前に10999以下のビルド番号を持つTH2のアップグレードが今後リリースされる可能性があることを示す）。

　現在のWindows 10はTH2と呼ばれる「ブランチ」が現行版として使われていて、Windows UpdateはこのTH2を修正するものになる。一方で並行して、RS1の開発が行われており、すでにWindows Insiderプログラムでプレビュー版の配布が行われている。簡単にいうと、これはTH2という「ブランチ」とRS1という「ブランチ」があり、並行して作業がなされている。

　しかし、ここで疑問を持たれる方もいるだろう。ブランチするとソースコードがコピーされて、TH2とRS1では別々の修正が行われる。そうすると、TH2用に行った修正は、RS1のほうには反映されないことになる。RS1にも同じバグがあった場合、修正を最初からやらねばならないのだろうか？

　まず、プロジェクトは独立したサブプロジェクトから構成されており、1つのサブプロジェクトの修正は原則、他のサブプロジェクトにはできるだけ影響しないようになっている（そもそもプロジェクトを最初にそのように切り分ける）。たとえば、メモ帳に問題があり修正を行っても、Windows自体やソースコードを共有しない他のアプリ、たとえば「電卓」に影響が出る可能性はほとんどない。このためサブプロジェクト内のみの修正であれば、他の部分を気にする必要がない。

　ブランチしたRS1では、TH2のすべてのソースコードを修正するわけではなく、中にはTH2と同じままの部分もかなりある。このため、修正がサブプロジェクト内で閉じているならそのまま利用できる。

　他のブランチで行った修正を作業中のブランチに反映させることを「マージ」という。ソースコードの修正が片方のみで、広範囲に影響を与えない「マージ」であれば、作業はほぼ自動で行える。大半の修正はこれに当たる。万一、RS1で修正しているソースコードがTH2のバグ修正で変更された場合は、開発者が両方を見て、適切に修正する必要がある（これを手動マージなどということもある）。

　このように「ブランチ」を使うことで、現行版、次世代版などを並行して開発することが可能になる。Windows 10 Pro以上には、TH1、TH2などの「アップグレード」を延期して、一定期間は、同じものを使い続けることができる「Windows Update for Business」などの機能がある。

　現時点では、アップグレードを延期していてTH1を使い続けているマシンとTH2にアップグレードしたマシンの2種類が存在する。このように並行して利用されるアップグレードをマイクロソフトは「ブランチ」と呼ぶ。

　TH1/TH2などのアップグレードがブランチとして開発されており、リリース後もそのブランチを維持しているからだと思われる。というのは、Windows Updateによるアップデートは、TH1とTH2で違って来るからだ。実際、最近のWindows Updateで配布されるアップデートには、「Windows 10 バージョン1511」といった表記があり、TH2にはTH2用のアップデートが配布されている。