連載：いまさら聞けないWindows Serverの開発活用術 第1回　Windows上で開発するための開発環境構築入門 亀川 和史 2012/05/16

Page1 Page2

　普段、Windowsを使ってチームで開発作業を行っている開発者であれば、何らかのサーバ（例：ソース・コードの置き場など）を利用しているだろう。では、そういったサーバのOSを選び、そのOSの各種設定をした経験はあるだろうか？ 「全くサーバ管理の経験がない」という開発者も意外と多いのではないだろうか？

　チーム開発では、メンバーの人数が多くなるほど、開発するシステムの規模が大きくなるほど、開発者間でのさまざまな混乱を避けるために、ソース・コード管理や、作業項目管理／バグ追跡などのチーム開発機能を活用する必要性は高まる。そういったチーム開発機能を使いこなすには、サーバの知識は必要不可欠だ。つまり、チームに所属する開発者であれば、物理サーバや仮想サーバも含めたサーバの使い方を知っているのが、当然のことなのである（そのため、今回の連載タイトルは「いまさら聞けない」となっている）。

　そこで本連載では、サーバ管理の経験があまりない開発者に向けて、Windows OSのサーバである「Windows Server」の基礎知識を開発者視点で紹介する（例えば、「このときは、この機能を、こう使う」という逆引きの形でOS機能を紹介する。ただし、紙面の都合上、全ての手順を細かく説明することはできない。そこで、手順などの詳細情報が必要な場合は、そのOS機能に関する参考記事へのリンクを用意するので、そのリンク先を読んでほしい）。

　今回は、「チーム開発に用いるWindows Serverの選択」「チーム開発に必要なソフトウェアの導入」「チーム開発に有用なサーバ設定」について説明する。

■チーム開発に用いるサーバOSを何にするか？

●まずはOS選び

　本稿では、開発に使用するOSは、

• サーバが「Windows Server 2008 R2」
• 開発クライアントが「Windows 7」

とする。

　現実的なエンド・ユーザーの利用環境の中には、「Windows XPもまだまだ主流である」というところも少なくはないだろう。Windows XP環境向けに開発する場合は、特別なハードウェアを併用する環境でもない限り、「Windows 7をホストにして、Windows XPを仮想環境で動作させる」と便利だ。

　次はエディション選び。筆者もWindows Serverで「どのエディションを使えばいいのか分からない」という相談をよく受ける。Windows Server 2008 R2の場合、「Foundation」「Web Server」「Standard」「Enterprise」「Datacenter」「Itanium」というエディションが存在する。この中から「Itanium」と「Foundation」は特定用途なので、除外する。また、Webサーバ機能に特化したエディション「Web Server」は、本連載で解説するチーム開発サーバには向いていないので、除外する。

　よって基本的には、「Standard」「Enterprise」「Datacenter」の中から適切なエディションを選択することになる。各エディションの違いは大きく分けて、以下の3通りになる。

• 使用可能なCPU／メモリの上限が高い
• 信頼性向上のための機能がある
• 運用面の制限が緩和されている

　チーム開発（例えばソース・コード管理や、作業項目管理／バグ追跡など）用のサーバとして使用する場合、CPUやメモリの上限のみ考慮すればよい。CPUは物理的に存在するCPUの個数が上限となっているので、現在のマルチコアではタスク・マネージャなどで認識しているCPU数と一致しないことに注意してほしい。メモリに関していえば、最近は32Gbytes以上搭載可能なサーバもあるので、32Gbytes以上のメモリを大量に搭載する場合、EnterpriseエディションもしくはDatacenterエディションを選べばよい。Datacenterエディションは通常、サーバとセットで販売されるため、開発で使用する場合はMSDNに含まれるライセンスを使用することになる。

　EnterpriseエディションはCPUおよびメモリの上限のほかに、クラスタリング（参考：「TechNet：Failover Clusters in Windows Server 2008 R2」）、証明書の自動発行機能（参考：「TechNet：Active Directory 証明書サービスの役割」）といった運用上有効な機能がそろっている。「Enterpriseエディションは値段が高くて、CPUとメモリの上限が緩和されているだけ」ではないので注意してほしい。

　詳細な一覧は以下のページにまとめられている。

• Microsoft：Windows Server 2008 R2 エディションの違い

【コラム】サポート・ライフサイクルについて

現在のマイクロソフトのサーバ製品には、サポート・ライフサイクルが決められている。本稿執筆時点において、サーバなどのビジネス向け製品は10年となっている。その後の事情により延長、変更されることもあるようだが、原則として10年ということを考慮しておく必要がある。開発関係でよく使用するソフトウェアのサポート・ライフサイクル情報は、以下のリンク先で公開されている。 サポート・ライフサイクル製品一覧 デスクトップ・サポート・ライフサイクル Windows Serverサポート・ライフサイクル SQL Serverサポート・ライフサイクル Visual Studioサポート・ライフサイクル

■チーム開発に必要なソフトをそろえよう

●Visual Studio

　Windows向けソフトウェアを開発する場合、現在の正式版レベルの最新開発環境はVisual Studio 2010であり、執筆時点では次期開発環境としてVisual Studio 11のベータ版が公開されている。Windows 8専用アプリケーションであるMetroスタイル・アプリを開発するためにはVisual Studio 11を使用しなくてはならない（参考：「特集：Visual Studio 11 Beta＋Windows 8 Consumer Previewファースト・インプレッション」）。

　Visual Studio 11ではMetroスタイル・アプリ作成だけではなく、.NET Framework 4.5開発でも多くの機能強化が行われており、特にクライアント側で「フリーズしない」、応答性のよいアプリケーションを作るための機能強化が多く行われている（参考：「フリーズしないアプリケーションの作り方」）。クライアント・アプリケーションには特に有用だろう。

　Visual Studio 11で開発を行う場合の注意点として、.NET Framework 4.5は.NET Framework 4を上書きするため、現時点では（正式な開発環境とは）完全に別の環境を用意して開発作業を行うことを推奨する。本連載では正式版の最新製品であるVisual Studio 2010で開発する。

●ソース・コード管理

　チームとして複数人で開発する場合、（次の図のように）ファイル・サーバの共有フォルダにソース・ファイルを置いて参照していないだろうか？ サーバ上の共有ソース・ファイルを手動で上書きしたり、マージしたりすると、人的ミスによって、ほかの人が新規追加したコードに上書きしてしまったり、場合によってはコンパイルできなくなってしまたりする可能性がある。バージョン管理ツール（＝ソース・コードを管理するためのツール）は、このような問題を解消してくれる。

ネットワーク上の共有フォルダを使ったチーム開発のイメージ

　このようなソース・ファイルの編集で競合する問題の解決よりも便利な点として、バージョン管理ツールは、一度修正したソース・ファイルを何らかの事情で元に戻したい場合に履歴から簡単に戻せたり、任意のタイミングのソース・ファイルと差分を比較したりすることもできる。

　「ネットワーク共有上に日付で毎日履歴を保存しているから、その履歴バックアップと比較すれば大丈夫」という現場も少なくないと思うが、その日にどんな修正を行っていたのかを覚えておくことなどはまずできないし、修正事項をExcelファイルで管理するというのも面倒だ。規模が大きくなると、このようなアナログな管理は現実的ではない。

　バージョン管理システムでソース・コードを管理している場合、開発メンバーはそれぞれバージョン管理システムのリポジトリから自クライアントPCのローカル・フォルダに開発用ソース・ファイルのダウンロードを行う。ソース・ファイルを編集後、リポジトリへの「チェックイン」を行うと、ほかの人が編集する場合も「最新のソースを取得」すれば常に最新のソース・ファイルで開発を行える。

　また、バージョン管理システムでは、ほかの人がチェックインしたソース・ファイルでどんな修正を行ったかを開発メンバーの誰もが後から参照できるし、チェックイン時点で過去の修正内容と比較する機能もあるため、より詳細にソース・コードの修正ポイントを確認できる。ソース・コードのバックアップもバージョン管理ツール側で実施しておくことにより、クライアントのバックアップ忘れによるソース・コードの消失という事態を最小限に食い止められる。

　複数人で開発する場合では、まずバージョン管理ツールを導入することが最初の一歩といってもいい。

　Visual Studioでは、バージョン管理ツールへのアクセス方法をプラグインとして組み込むことができる（Visual Studio 2010 Express Editionは不可）。オープンソースおよび、市販製品でいろいろなバージョン管理システムが用意されている。ここではVisual StudioやEclipseと組み合わせて使用する「Team Foundation Server」を紹介する。

　オープンソースでは「Subversion」や「Git」、「Mercurial」など（順に、「サブバージョン」「ギット」「マーキュリアル」と読む）が有名であり、GitとMercurialはマイクロソフトが運営するCodePlexというオープンソース公開サイトでも使用されている。

【コラム】無償版Team Foundation Server（登場予定）について

Team Foundation Server 2010は有償製品だが、次期Visual Studio 11では5人までの小規模チーム向けに無償の「Team Foundation Server Express Edition」が提供されるという告知があった（参考：「Coming Soon：TFS Express - bharry's WebLog - MSDN Blogs（英語）」）。有償製品ということで二の足を踏んでいた小規模開発向けにも導入しやすいと思う。製品版がリリースされたらぜひ試してほしい。 　Team Foundation Serverはソース・コードのバージョン管理だけではなく、自動ビルド、作業項目管理、品質レポート表示機能……と盛りだくさんの機能が用意されている（参考：「連載：Team Foundation Server 2010入門」）。最初はソース・コード管理と作業項目トラッキングから始めて、次のステップで自動ビルドも使い始めるといいだろう。

●作業項目の管理とバグ・トラッキング管理

　チームで開発を行う場合、「誰が」「どの」作業を「いつまでに」行うという管理は非常に重要である。担当者が決まっていないと、リリースまでに完了しておかなければならないバグ修正が行われなかったり、機能の実装が行われなかったりすることがある。また、作業タスクを事前に入力しておくことにより、開発メンバーでやらなくてはならないことが共有される。

　作業項目の管理を行うことにより、Team Foundation Server内で誰が作業をどのくらい行うかという情報が蓄積される。Team Foundation Serverでは、蓄積されたデータを基にして、各メンバーの負荷状況をレポート機能で出力できる（参考：「MSDN：プログラム管理オフィスでのアジャイル チーム進行状況の可視化」「快適な進ちょく管理を実現する作業項目トラッキング」）。

　このようにレポートで表示されると、管理者が特定のメンバーに負荷がかかっているという状態が可視化され、非常に分かりやすい。「このバグの担当者は本来、A君だが、A君の負荷が高いので、B君にお願いする」という調整ができるようになる。作業項目と作業時間管理が1つのツールでまとまっているという点は非常に便利だ。

　しかし、開発に役立つ多くの機能をサーバ側で提供するのは便利だが、そのサーバ群を何も考えずに運用していると、運用コストが高くなってしまい、開発作業に影響を与えてしまう。Windows Serverには複数のサーバを効率的に運用するための機能が用意されている。

　次のページからは、複数のWindows Serverを効率的に管理する方法について紹介する。

INDEX
	［連載］いまさら聞けないWindows Serverの開発活用術
	第1回　Windows上で開発するための開発環境構築入門
	1．チーム開発に用いるサーバOSを何にするか？／チーム開発に必要なソフトをそろえよう
	2．チーム開発用サーバの基本設定

「いまさら聞けないWindows Serverの開発活用術」

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