検索
連載

第2回 自動ビルドを実現するビルド・サービスの必要性と環境構築方法連載:いまどきのソース・コード管理(1/3 ページ)

ソース・コードの管理環境の構築の次は、自動ビルド環境を構成しよう。Team Foundation Server Expressに統合されているビルド・サーバ機能を活用すれば、これも簡単に構築できる。

Share
Tweet
LINE
Hatena
連載:いまどきのソース・コード管理
業務アプリInsider/Insider.NET

powered by Insider.NET

「連載:いまどきのソース・コード管理」のインデックス

連載目次

 前回の記事ではソース・コードの管理環境の構築について解説した。今回〜次回は次のステップとして、自動ビルドを構成してみよう。

 自動ビルドとはその名のとおり、ユーザーが直接操作することなく、サーバ上で自動的にコンパイルおよび、場合によってはテスト環境への登録も行うというものだ。Team Foundation Server(以下、TFS)および、Team Foundation Service(以下、TF Service)にはこのような自動ビルドを実現するビルド・サーバ機能が統合されているため、自動ビルド環境は非常に簡単に構築できる。

なぜビルド・サービスが必要なのか

 TF Serviceおよび、フル機能版のTFSだけではなく、TFS Expressにも自動ビルドを提供する「ビルド・サービス」が機能として提供されている。ビルド・サービスのような自動ビルドは、チーム開発においてそれだけ基本的、かつ重要な機能であるということだ。それだけ重要な「ビルド・サービス」について解説する前に、「なぜビルド・サービスのような、(個別のマシンではなく)中央でのビルド環境でビルド・サーバを構築する必要があるのか?」という点について考えてみよう。

 確かに1人で数台のPCだけを使用して開発からテスト、デプロイまでの全てを行っている場合は、TFSにビルド・サービスをインストールしたり、自動ビルドを構成したりする必要はないかもしれない。しかし、複数のソリューションで構成されるある程度の規模のプロジェクトを、複数人で開発している場合、ある開発者が変更した箇所が別の開発者が使用しているソース・コードに影響を与えてしまうことがある。

 このような問題が比較的発生しやすいのは「インターフェイスの変更(例えばメソッド・シグネチャの変更など)」をした場合だ。ただしインターフェイスの場合には最終的にコンパイルできなくなるためすぐに発見できる。

 しかし、インターフェイス以外の修正、例えば内部動作の仕様変更の場合は、実際に依存関係のあるモジュールを結合してテストを行わない場合、変更後のコードに問題があるのが発見できないことも多い。特に規模が大きくなると、自分が担当していないソース・コードやライブラリのバージョン・アップを行わず、少し古いリリース版で開発し続けることもあるため、(自分の開発環境では問題なく動作しているコードであっても)ほかのチーム開発者のコードと結合する開発後期にならないと問題が発見できないということもしばしば起きる。

 開発末期時点で一度に結合して、本番前のテストを行うと、動かないことも起こり得る。このような結合ミスを防ぐには、インターフェイスや仕様を変更するなど、破壊的な変更を行ったときに、「どこに影響や問題が起きるか」を確認するためにも、定期的に(例えばチェックインを行うタイミングなどで)プロジェクト全体がビルドされるようにしておけば、破壊的な変更を行った場合でも即座にその影響範囲をある程度は把握できるようになる。

 もちろん、プロジェクト全体のソース・コードを取得して個々のローカル環境でこのような作業を行ってもよい。だが、中央にビルド・サーバを構築して、そこにテスト定義を適切に作成すれば、時間のかかるビルドやテストはサーバに任せられるようになる。サーバ上でビルド&テストを実行している間、自分はほかの作業を行えるので、ビルド・サーバの方が(ローカル環境よりも)効率的だ。

 チーム開発を行う場合、(筆者の経験では)このような自動ビルドから自動テストまでの過程を(チーム開発者全員に慣れてもらい)軌道に乗せるには多少の時間が必要だが、乗ってしまえばあとは基本的に機械に任せられる。人間が手作業でビルドするとミスや確認に手間ばかりがかかって疲れてしまうが、機械はいくらビルドを回しても疲れることはないのだ。

 開発のペースを上げるため、そして人間の(身体的/精神的な)平穏のためにも、ビルド&テストを継続的に実行する「継続的インテグレーション」への第一歩となるビルド・サーバをぜひ用意してほしい。

 なお、本稿ではオンプレミス版のビルド・サーバとしてTFS Express 2012を、オンライン・サービス版のビルド・サーバとしてTF Serviceを取り上げる。以降では、TFS/TF Service全般を指す場合には「TFS」、TFS Expressのみを指す場合には「TFS Express」、TF Serviceのみを指す場合には「TF Service」と記述する。

Visual Studio 2012 Update 2について

 日本時間の2013年4月5日に、Visual Studio 2012の第2回更新版であるVisual Studio 2012 Update 2の正式版が公開された。ビルド・サービスに関しての変更点はないため、本記事に関してはUpdate 2でも影響するところはないが、テスト機能をはじめとしてさまざまな機能強化が図られているため、TFSと併せて適用してほしい。


 前回はTFS Expressを例に、オンプレミス版のTFSのインストールとサーバでの初期チーム・プロジェクトの作成までを行った。引き続き今回は、自動ビルドを行うためのTFSのビルド・サービス構成手順を(次のページから)見ていくことにしよう。

Copyright© Digital Advantage Corp. All Rights Reserved.

       | 次のページへ
ページトップに戻る