第4回の連載では、チーム開発におけるリポジトリ管理のポイントをご紹介しました。第5回は、チーム開発におけるビルド管理についてご紹介します。

今回取り上げるビルドの定義とは?

一般的にビルドというと、統合開発環境(IDE＝Integrated Development Environment)でおこなう「コンパイル→リンク→パッケージング」というプロセスのフローを指します。これは狭義のビルドと呼べるでしょう。

しかし本来の目的に立ち返れば、「実行可能なアプリケーションを得るためにおこなう」行為をビルドと考えることができます。解釈を少し広げてWebシステムを例に考えると、「実行可能なシステムを得るため」には、実行ファイルを作成するだけでなく、テストをおこなった後のWebサーバへのデプロイやDBサーバへのマスターデータの投入が必要です。このように「複数のプロセスを組み合わせて利用可能な成果物を提供する」という行為も広義ではビルドと呼べます。本稿で取り上げるビルドの定義は、後者の広義のビルドを指しています。

広義のビルドと狭義のビルド

ビルドを管理して複雑なプロセスをシンプルに

広義のビルドについて考える場合は、プロセスの前後関係や依存関係が巨大かつ複雑になりやすいため、ビルドの管理を意識する必要性が出てきます。ここでの「ビルドが管理されている」とは、ビルドの各プロセスに対して開始条件と実行条件、終了条件、入力、出力、フローが明示的に定義されている状態を指します。

正しく管理されているものはコンピュータによる自動化が可能です。「実行ファイルを作成する」というビルドはIDEによって自動化されていました。また、フローが明確になっているため、IDEはパッケージングの後に静的コード解析やユニットテストのプロセスを追加して新しい機能を提供できます。すなわち、ビルドにおけるプロセスのフローが定義されていれば、別のプロセスと組み合わせて新しいビルドを作成することができるようになるのです。

開発の速度と品質を高めるプラクティスを適用するためには?

現在では、IT技術の進歩とともにビジネスは目まぐるしく変化し、それに対応すべく、ITシステム開発にはこれまで以上の速度が要求されています。また、ITシステムの障害によるビジネスに与える影響が大きくなっているため、品質に対する要求もより高くなっています。これらの要求に応えるプラクティスは数多く提唱されていますが、ここでは、ビルドの自動化と関係が深いContinuous Integration(CI)およびContinuous Delivery (CD)について説明します。

CIは、実行ファイルの作成とテストの実施を自動化し、常に実行可能な状態でソースコードを管理するプラクティスです。その目的は、プログラムの結合時に起こる問題の早期発見やリファクタリングの実施によって、ソースコードの品質を向上させることです。

CDは、実行ファイル作成やデプロイ、データ投入等の手順を自動化し、常に実行可能なシステムを提供するプラクティスです。その目的は、システム全体が完成する前からUIテストをおこない、ユニットテストでは検知しにくい問題を発見することです。さらに、近年ではUIテストに関しても自動化をおこなうケースが増えてきています。

これらのプラクティスを組み合わせることにより、「常に実行可能なシステムを安定した状態で提供する」ことができるようになります。これも前述した広義のビルドと考えることができます。

いずれのプラクティスもビルドの自動化が必須となります。しかし、単に自動化しただけでは、ある人の環境ではビルドが成功するのに、別の人の環境ではビルドが失敗する、といった問題が起こりがちです。それを防ぐにはビルド専用の環境が必要になりますが、環境をただ用意するだけではなく、ソースコードのリビジョンやビルド結果、テスト結果などがひもづいている必要があります。ビルドツールの支援を受けることでこれらの情報をひもづけるのに必要な労力を大きく減らすことができます。

チームで必要とする機能やコストに合ったビルドツール選択を

CIやCDのプラクティスを実践する場合、構成管理リポジトリやチケット管理ツール、テストツール、レポーティングツールといった多数のツールと連携する必要があります。

単独の機能に特化したツールを個別に連携させた場合には、それぞれのツールに情報が分散されてしまうため、必要な情報を参照のにツールを頻繁に切り替える必要があります。一方、これまでの連載で紹介してきたTeam Foundation Server(TFS)/Visual Studio Online(VSO)といった包括的なツールを導入した場合には、すべての情報がTFS/VSOで管理されているため、ソースコードのリビジョン確認およびビルド結果やテスト結果の履歴を参照する際に、それぞれの情報を管理しているツールに個別にアクセスする必要がなくなります。

さらに近年では、クロスプラットフォームやマルチデバイスへの対応が要求されることがありますが、TFS/VSOではエージェントと呼ばれる機能を使って、ビルドの管理とビルドの実行を分離させることで、WindowsアプリやAndroidアプリ、iOSアプリ等のビルドを一括して管理できるため、これらの要求に応えることができます。

包括的なツールとなると導入コストが高くなると思われがちです。しかし、単独の機能に特化したツールを個別に連携させた場合、それぞれのツールのイニシャルコストは低く見えても、導入・運用・連携・学習等のランニングコストを考慮するとトータルコストは想像以上に高くなります。第2回の連載でご紹介したようにTFS/VSOを無償で利用する方法もありますので、単独のツール群と連携させる場合と比較した上で、皆さんのチームに適したビルドツールを選択するとよいでしょう。

今回はビルドという言葉の意味や、ビルドの管理の重要性について説明をおこない、ビルドの自動化により実現できる開発プラクティスについて説明しました。次回の第6回は、チーム開発における運用監視についてご紹介します。

編集協力:ユニゾン

執筆者紹介

TFSUG(Team Foundation Server User Group) 串田悠彰

2009年より製造業向けの生産管理や在庫管理のコンサルティングやシステム開発に関与。チーム開発のプロセスを改善する方法を模索している時にTFSUGに遭遇。ツールそのものよりもビジネスやプロセスに主眼をおいたコミュニティの方針に共鳴し、2014年よりスタッフとして参加。TFSUGの他、プロジェクト&プログラムアナリシス研究部会にも頻繁に参加している。会社員かつ個人事業主かつ代表取締役の三つの顔を使い分けてひっそりと活動中。