Visual Studio .NETによるチーム開発事始め 効率のよいソース管理を実現しよう デジタルアドバンテージ 2004/03/10

Page1 Page2 Page3 Page4

Back Issue

Visual C# .NETでAPIリファレンスを作る（前編） Visual C# .NETでAPIリファレンスを作る（後編） Visual SourceSafeによるソース管理（準備編） Visual SourceSafeの環境を構築する Visual Studio .NETを使ったソース管理の実践 Visual SourceSafeを使いこなす

　これまで本連載は、マイクロソフトの統合開発環境「Visual Studio .NET（以降、VS.NET）」と、同マイクロソフトのソース管理ツール「Visual SourceSafe（以降、VSS）」を組み合わせてソース管理を行うための基本的な操作方法について解説してきた。つまり、本連載のこれまでの主な内容は、開発者がVS.NETでソース管理を行うことを念頭に置いたものだった。VSSの連載の最終回である今回は、その視点を離れ、管理者から見たVSSの活用法やVSSの将来などについて説明していくことにする。具体的には、バッチ処理ファイルによるソース管理作業の自動化、VS.NET 2003で導入されたソリューション・ルート、ピン設定／共有／分岐の機能、次期VSSで追加される新機能などについて説明する。

　それではまずは、バッチ処理ファイルの自動処理から解説することにしよう。

1. バッチ処理ファイルによる自動処理

　VS.NETを使ったソース管理は、開発者にとって非常に有益である。これは、前回までの記事を読めば納得していただけるだろう。なぜなら、VS.NETを使えば、VSSデータベースへのソリューションの追加やプロジェクトの追加、ソース・ファイルのチェックアウト→編集→チェックインなどの作業を、開発環境から簡単かつシームレスに行うことができるからだ。

　しかし、ソリューションのアルファ版／ベータ版／製品版など、煩雑な複数バージョンの管理をしているソース管理者やそのバージョンごとのビルドを担当しているビルド担当者（以降、「ソース管理者／ビルド担当者」）にとって、開発環境からのソース管理だけではさほど有益ではないと思われる。

　例えば、ソース管理者／ビルド担当者が結合テストやシステム・テスト（＝総合テスト）用に毎回、ソリューションのビルドを行わなければならないという状況を想定してみよう。この場合、ビルドのために、まずVisual Studio .NETを起動する必要がある。起動した後、［最新バージョンの取得］を実行して、ソリューションの最新リビジョンをローカル環境に取得し、そしてVS.NETを使ってそのソリューションのビルドを行わなければならないだろう。

　このような「ソリューションを取得してビルド」という作業は、新しいバージョンが出てくるたびに必要になる。しかも、昨今の開発プロセスでは反復型開発（参考：自分戦略研究所「プロジェクトマネージャならば理解しておこう」）を採用することも多いので、バージョン・アップが頻繁に発生する可能性がある。そのため、これと同じ作業を頻繁に何度も繰り返すことになる。つまり、ここでソース管理者／ビルド担当者が行わねばならないソース管理作業はルーチン（定形的な）ワーク（作業）といえるだろう。

　このようなルーチン・ワークを効率的に行う手段の1つとして、コマンドラインによるバッチ処理ファイル（拡張子.batまたは.cmdのファイル）を挙げることができる。バッチ処理ファイルを使えば、処理を一括でしかも自動的に行うことができるので、ソース管理者／ビルド担当者は退屈なルーチン作業から解放される。それだけではなく、手作業による人為的なミスも削減可能だ。

　幸いなことにVSSでは、VSSエクスプローラなどのGUIツールだけでなく、バッチ処理ファイルから呼び出して使えるコマンドライン・ツールも用意されている。このVSSコマンドライン・ツールを使って、バッチ処理ファイルを記述できるのだ。

　それでは実際に、VSSコマンドライン・ツールを使ったバッチ処理のスクリプト・ファイルを作ってみることにしよう。

■バッチ処理ファイルの作成

　ここでのバッチ処理ファイルの実行内容は、「ソリューションの最新のリビジョンを取得して、そのソリューションのビルドを行うもの」とする。これによりビルドされたソリューションを、テスター（テスト担当者）が結合テスト／システム・テストするという想定である。また、このバッチ処理ファイルの実行は、ビルド専用のサーバ環境で行うものとする。

　バッチ・ファイルがまず最初に行う作業は、「ソリューションの最新のリビジョンの取得」である。これを行うVSSコマンドライン・ツールは、VSSのインストール先のWin32フォルダにあるSS.EXEだ。本稿の例のとおりにインストールを行っていれば、「C:\Program Files\Microsoft Visual Studio\VSS\win32」にSS.EXEがあるはずである。

　このSS.EXEを使ってVSSを操作する。SS.EXEでも、VSSエクスプローラやVS.NETのときと同様にログイン処理が必要だ。バッチ処理ファイルの最初には、そのログイン処理を記述する。バッチ処理ファイルとして、ここでは仮に「teamdev.bat」という名前でテキスト・ファイルを作成し、メモ帳を使ってそれを編集する。そのファイルの先頭部分は次のようになる。

set ssUser=BuilderA　… set ssPwd=teamdev　… set ssDir=\\Win2003\VSS_BlogX\　…

ログイン設定を記述したバッチ処理ファイルの先頭部分

VSSユーザー名（この例では「BuilderA」）を指定する。 　 パスワード（この例では「teamdev」）を指定する。この例では直接記述しているが、パスワードは本来ならセキュリティのため指定しないことをお勧めする。 　 使用するVSSデータベースのパス（この例では「\\Win2003\VSS_BlogX\」）を指定する。

　この「ssUser」にはVSSのユーザー名（この例では「BuilderA」）を、「ssPwd」にはパスワード（この例では「teamdev」）を、「ssDir」には使用するVSSデータベースのパス（この例では「\\Win2003\VSS_BlogX\」）を指定する。

　ssUserはソース管理者／ビルド担当者になるが、それが必ずしも開発者とは限らないし、実際の開発者とは役割が違う。よって、ビルド専用のユーザーを新しく用意した方がよいだろう。なお、ユーザーの追加方法については以前の記事で解説済みなので、詳しくはそちらを参照してほしい。

　ssPwdは、安全のためスクリプト・ファイルには記述しないことをお勧めする。ここでssPwdを記述していない場合、バッチ処理ファイルの中でSS.EXEが呼び出されると、パスワードの入力が要求されるようになるだけだ。もちろん、ssPwdなどすべての情報を指定している場合は、そのまま自動ログインできるというメリットもある。

　次にソリューションの取得を行う。これには、次の例のようにSS.EXEをオプション付きで呼び出す。

VSSコマンドライン・ツールの実体。このツールにオプションを付けて呼び出すことで、さまざまなソース管理作業を行うことができる。この例では、ソリューションの最新のリビジョンを取得している。 　 Getコマンドを指定すると、読み取り専用でソリューションのコピーを取得できる。 　 VSSデータベースにおけるソリューションのフォルダ（この例では「$/BlogX」）を指定する。 　 -Wスイッチを指定すると、ローカルに取得したソリューションのコピーを書き込み可能にすることができる。のGetコマンドでソリューションのコピーを取得する場合、デフォルトですべてのファイルが読み取り専用になってしまうため、書き込み可能にするにはこのオプションが必要である。 　 -Rスイッチを指定すると、指定したソリューション（もしくはプロジェクト）階層以下のすべてのファイルを取得できる。 　 -I-Yスイッチを指定すると、ユーザーへの入力要求が一切行われないようになる。これにより、すべてYesで答えたこととして動作する。なお、Noで答えるには-I-Nスイッチを使えばよい。 　 -GL<パス名>スイッチを指定すると、指定したパス（この例では「C:\BuildDir」）にソリューションを取得できる。このスイッチを指定していない場合は作業フォルダに取得される。なお、作業フォルダの指定については前回で解説した。

　これによって、最新のリビジョンのソリューションを取得できる。なお、最新のリビジョンではなく、バージョン・ラベルを指定してソリューションを取得したい場合は、上の記述にさらに「-VL（Version Label）スイッチ」を追加すればよい。

-VL<バージョン・ラベル名>スイッチを指定すると、最新のリビジョンではなく、指定したバージョン・ラベルのソリューションを取得できる。この例では、「Version 1.1 Beta」というバージョン・ラベルのソリューションを取得している。

　最後に、VS.NETを呼び出して、取得したソリューションのビルドを行う。これには、バッチ処理ファイルに次のような記述を加える。VS.NET（devenv.exe）はオプションを付けて実行することにより、コマンドラインからもソリューションのビルドなどが行えるようになっている。

Visual Studio .NETの実行ファイル 　 ビルドするソリューション・ファイル（この例では「C:\BuildDir\BlogX.sln 」）を指定する。このソリューション・ファイル（拡張子.slnのファイル）には、上で述べたVSSコマンドライン・ツールで取得したソリューションの中のファイルを指定する。 　 /rebuildオプションを指定すると、ソリューション全体をリビルドできる。逆にこれを指定しないと単なるビルドになる。 　 ビルドの構成（この例では「Release」）を指定する。

　以上の解説で示したコマンドライン処理を含むサンプルのバッチ処理ファイルを用意した。ここからダウンロードできるので、ぜひ実際にバッチ処理ファイルを作成するときの参考にしていただきたい。なお、誤って実行してしまわないように、バッチ処理ファイルの拡張子を「.txt」にしているのでご注意いただきたい。実際に実行するは、拡張子を「.bat」にする必要がある。なお、バッチ処理ファイルで利用できるコマンドラインについては、Windows Server Insiderの「Windows 2000 コマンドライン徹底活用」を参照されたい。

　本稿のバッチ処理では、ソリューションの取得とビルドしか行っていないが、ほかにも.NETアセンブリのバージョン更新やMSI（Microsoft Installer）パッケージの作成などもバッチ処理ファイルで実行できるようにするとよいだろう。また、本稿ではバッチ処理ファイルを作成したが、WSH（Windows Scripting Host）を使ってもよい（参考「Windows管理者のためのWindows Script Host入門」）。このバッチ処理ファイルに盛り込むべき内容は、MSDNの「Visual Studio .NET と Visual SourceSafe を使用したチーム開発：ビルド プロセス」という文献が参考になる。また、この文献に則したツールに「BuildIt」というのがあるので、それを使ってもよいだろう（ただし、日本語環境で完全に動作するかどうかは未確認）。

INDEX
	Visual Studio .NETによるチーム開発事始め
	効率のよいソース管理を実現しよう
	1．バッチ処理ファイルによる自動処理
	2．VS.NET 2003の新機能「ソリューション・ルート」
	3．ピン設定および共有／分岐について
	4．次期VS.NET“Whidbey”と同時リリースされる次期VSSの新機能

　

「Visual Studio .NETによるチーム開発事始め」

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）