カテゴリー: TFS/Azure DevOps Server

今回使用したbuild.gradleの内容について説明です。

まずはGradle用プラグインの宣言です。
これは使用したいプラグインを記述するだけです。
但し、JUnitについてはJavaプラグインに含まれているので指定する必要はありません。

次は各タスクに対する共通的な設定です。

8行目でソースコードの文字コードはUTF-8であること、9～10行目でFindBugsとcheckstyleのチェック内容でエラーが検知されても、ビルドは中断しないことを指定しています。

次はソースコードの格納場所についてです。

今回、ソースコードのフォルダ構成はGradle標準ではなく、Antの構成にしているので、リリース対象のソースコードとテスト用のソースコードのパスを変更します。

次は各種ライブラリのリポジトリに関するものです。

ざっというと
　・リポジトリはIvyを使用する
　・リポジトリの公開パスは「http://tfsba01/ivy_repos」
　・ライブラリの保存場所のパスは「artifact　～」のパターンで検索
　・依存関係の情報は「ivy "～」で指定されたファイルを参照する
という設定です。もう少し詳細な内容は別の機会にしたいと思います。

次は使用するライブラリの指定です。

これは
　・テスト用ソースのコンパイルでは、junitのバージョン4.0以上とhamcrest-coreの1.0以上を使用する
　・checkstyle実行時では、checkstyleのバージョン6.1.1を使用する
という内容になっています。
ここで指定したライブラリが別のライブラリを使用する場合は、repositoriesで指定したリポジトリを使用してライブラリ間の依存関係を解決します。

次はJarファイルの作成についてです。

出力するファイル名を指定します。ちなみに、出力先フォルダは「libs」になります。

次はjacoco（テストカバレッジ取得）の動作設定についてです。

最初のブロック（「jacoco {～」）で、使用するバージョンを指定しています。
なぜか、jacocoだけはここで指定します。

2番目のブロック（「test {～）で、jacocoの設定をします。今回は、カバレッジ取得結果は毎回上書き（前回作成したファイルに追記しない）としているだけです。

3番目のブロック（「jacocoTestReport {～）で、レポートに関する設定をします。
「reports {～」のブロックで、xmlレポートとcsvレポートは出力しない設定にしています。
最後の1文は、タスクの依存関係の設定で、「buildタスクが終わったらjacocoTestReportタスクを実行する」ように指定しています。
ちなみに、このビルドスクリプトでは「jacocoTestReport」が最後のタスクになるので、ビルド定義の「Gradle task(s)」に、この「jacocoTestReport」を指定し、全てのタスクを実行するようにしています。

次はcheckstyleに関する設定です。

「checkstyleMain」が、リリース対象のソースコードに対するタスク設定になります。
「configFile=～」で、チェックパラメータファイルの保存先を指定しています。
「doLast {～」で、Antを個別に呼び出し、事前に作成されたxml形式の結果ファイルを元に、「checkstyle-simple.xsl」テンプレートを使用し、html形式のレポートを作成しています。
※「doLast」は、「タスクの一番最後に実行します」といった感じの宣言です。

「checkstyleTest」は、テスト用ソースコードに対するタスク設定ですが、「<< {}」としているので、「何もしない」ということになります。

次は、FIndBugsに対する設定です。

「findbugsMain」は、リリース対象のソースコードに対するタスク設定になります。
「reports {～」で、xml形式のレポートは生成せず、html形式のレポートは生成する指定にしています。
checkstyleのときと違い、レポート生成は何も指定しなくても自動で実行してくれます。

「findbugsTest」は、「checkstyleTest」同様テスト用ソースコードに対するタスク設定ですが、「<< {}」としているので、「何もしない」ということになります。

概要としては以上になります。各プラグインの詳細については、Gradleのドキュメントページにありますので、そちらを参照してください。

次は、ライブラリのリポジトリとして今回使用した「Ivy」についてです。

今回は作業項目から変更セットを取得するところです。

いろいろ処理が詰まっているので、番号を振ってみました。
また、一画面で入りきらなかったので、前半／後半に分けました。

①バージョン管理オブジェクトを取得しています。また、ファイル情報を格納するためのコレクションを作成しています。

②WIQLで取得したWorkItemCollectionからforeachでWorkItemを取り出します。

③作業項目に関連づけれらているリンクを取得します。foreachが使えなかった（と思います）ので、forで回しています。

④作業項目にはいろんな情報をリンクすることができますが、今回は変更セットへのリンクだけを取り出したいので、LinkクラスのArtifactLinkTypeプロパティを使い、リンクの種類が’Fixed in Changeset’でなければ処理対象外としています。

⑤リンクの内容から変更セットにアクセスします。
　リンク内容としてセットされているのが「vstfs:///VersionControl/Changeset/18」という形式になっています。最後の数字部分が変更セットのIDになりますので、これを抽出します。
　抽出した変更セットIDを使って、バージョン管理オブジェクトから変更セットの内容を取得します。

⑥変更セットのコレクションをループで回して変更対象のファイル一覧を作成します。

後半部分です。


⑦変更セットには、分岐（ブランチ）／ロックなどの修正以外の情報も格納されているので、ChangeクラスのChangeTypeを参照して修正対象のみを抽出するようにしています。←IsCollectChangeType()
　ChangeTypeの詳細は「ChangeType Enumeration」にあります。
　また、フォルダの変更情報も変更セットに格納されているので、Change.Item.ItemTypeを参照してファイルのみを抽出対象にしています。←IsCollectItemType()

⑧取得したファイルがファイル一覧のコレクションになければ追加、存在すればChangeTypeの内容を追加しています。

基本的にはTFSの標準機能で大体のことは対処できるのですが、こんな感じでTFSから情報を取得するコマンドが簡単に作れますので、自分の開発チームによっては「かゆいところに手が届く」感じのツールを作ることもできます。
今回のネタは自分が欲しかったので作ってみました。

実際に仕事で使うのはいつだろう・・・w

接続の前にmain()部分です。

関連処理はTfsWorkItemクラスに入れています。
GetWorkItemsFromId()で作業項目IDから作業項目のリストを取得し、GetChangeFileList()で作業項目内の変更セットからファイル一覧を取得しています。
後は、取得したファイル一覧を単純にコンソールに出力しているだけです。

まずはTFSへの接続です。

チームプロジェクトコレクションのURLを引数にして、Microsoft.TeamFoundation.Client.TfsTeamProjectCollection()を呼び出すだけです。これだとOSユーザでTFSに接続しますので、OSユーザと異なるユーザ情報でTFSに接続したい場合はCredentialsを引数に追加してください。
ここでは、作業項目管理オブジェクトであるWorkItemStoreも取得しています。

次に作業項目の取得です。

WIQL(Work Item Query Language)というSQLに似たクエリ言語を使用して作業項目のリストを取得します。詳細については、MSDNの「バグ、タスク、およびその他の作業項目の照会」で確認してみてください。但し、項目名称は英語版を元に記載されているため、日本語版のTFSでは「フィールドがない」と怒られてしまいます。項目名称は画面上で表示される名称がそのまま使用可能なのですが、コマンドで確認することも可能です。それについては別の機会に説明したいと思います。

今回は一旦WorkItemsから作業項目自体を取得し、作業項目からリンクをたどるようにしています。ちなみですが、リンクを取得するだけであれば、「From WorkItemLinks」で取得可能なのです。
Queryメソッドの戻りはWorkItemCollectionですので、ループでぶん回せば作業項目を取得できます。

次はforeachでぶん回して変更セットから変更ファイルのリストを取得するところです。

TFSではプログラムチェックイン時に作業項目に関連付けしておくことで、どの作業項目でどのファイルを修正したかがトレースできるようになっています。

変更セットのところをダブルクリックすると、チームエクスプローラーに変更セットの詳細が表示されます。

これはこれでいいんですが、画面で都度操作しないとファイル一覧が取得できません。
また、１つの作業項目に複数の変更セットがリンクされていると、それぞれに対して変更セットを確認する必要があります。

ちょっと面倒なので、TFS APIを使って指定した作業項目にリンクされている変更セットを検索し、修正ファイル一覧をコンソールに出力するプログラムを作ってみました。

コマンドプロンプトで、接続先チームプロジェクトコレクションのURL・作業項目種類・作業項目IDを指定すると、その作業項目のリンクされている修正ファイル一覧を出力します。

このプログラムをGitHubにて公開しました。
https://github.com/BlackSSI/ListupEditFileFromWorkItem
※いつものことですが、at your own riskです。あと、サンプルソースの公開用ですのでプルリクされても対応いたしかねます。（作り方が良くないのはご勘弁ください(^-^;）

次からは、処理の内容について説明します。

今回は小ネタです。

TFSでは「作業項目」（他システムだと「チケット」「Issue」とかですかね）を登録・管理することができます。
VSSなどの純粋なバージョン管理システムから移行された方にはぜひ使ってほしい機能です。作業項目にリンクすることで、いろんな管理ができるようになります。
（「この作業項目で修正したソースファイルは？」など）

作業項目の中に「残存作業」という項目があります。
通常は、ウォーターフォール開発だと「作業見積時間」、アジャイル系だとチーム内で話し合った作業量（ベロシティ）を設定することになるかと思います。
（作業見積時間だと、単位は分・時間・日などプロジェクトで共通化されていればなんでもいいのですが、「時間」を設定すれば一番きれいに使えます。ベロシティを設定する場合は、単位なんてありません）
これを設定し、開発者が定期的に残存作業を更新していれば、TFSが持っているレポート機能で「バーンダウンチャート」を出力し、進捗度を簡単に捉えることができます。

ただ、「厳密な進捗管理は別管理なのでTFSで入力すると２重管理になる」といった理由がある場合、「残存作業」には何も入力しなくても作業項目は登録できるのですが、せっかくのレポート機能が生かせなくなります。

「ちょっともったいない」と感じた方、こんな使い方があります。
　・作業項目作成時、「残存作業」に’1’をセットする
　・開発者は残存作業は変更しない
　・対象作業が完了した際は、「状態」を「作業完了」に変更する
こう使うことで、時間レベルでの残存作業管理ではなく、作業項目単位での残存作業管理となります。バーンダウンチャートは「どれだけの作業項目が消化できたか」という視点でのチャートになります。
また、「残存作業」は最初にセットするだけなので、開発者の負担が増えることはありません。
作業項目に対する作業量が一定量ではないので、「進捗管理はこれでバッチリ！」というわけにはいきませんが、進捗度合いを確認するきっかけには使えるかなと思います。

Visual StudioとEclipseを両方使う環境（例：JNIを使用するアプリを作成する）で、どうワークスペースを作ればいいかいろいろ悩んだので、メモ代わりに書いてみます。
まずはワークスペースの前提知識の整理です。

○ワークスペースについて
Team Foundation Serverを使用した開発で意識しないといけないものに「ワークスペース」があります。ワークスペースは、TFS上で管理されているソースコードをローカル環境のどのフォルダで変更するかのマッピングを管理するためのものです。

まっさらな環境で、１つのチームプロジェクトだけを対象に開発をするのであれば意識しなくてもよいのですが、複数のチームプロジェクトを対象にする場合、
　プロジェクトＡの開発作業を行っている
　　↓
　プロジェクトＢの緊急変更対応が入る
　　↓
　プロジェクトＢの変更が完了したので、チェックインする
　　↓
　プロジェクトＡの開発内容までチェックインされてしまう( ﾟДﾟ)
といったことが発生してしまいます。
チェックイン時にプロジェクトＢの変更内容を対象外にすれば大丈夫なのですが、急いでいる場合はうっかりチェックインしてしまう可能性があります。

これを避けるには、ワークスペースをチームプロジェクト毎に作成し、ソースコードの変更管理がチームプロジェクト単位で分離できるようにします。
（分岐を使用する際にワークスペースを分岐ごとに作成するのもこのためです）
※チームプロジェクトコレクション配下をすべて１つのワークスペースに割り当てることもできますが、通常はチームプロジェクト単位、もしくは分岐するフォルダ単位で割り当てます。

○ワークスペースの種類
Team Foundation Server 2010／Visual Studio 2010以降は、
・サーバーワークスペース
・ローカルワークスペース
の２種類のワークスペースが作成可能です。
※Visual Studio 2010以前の環境で使用できるのはサーバーワークスペースだけです。

MSDNの「ローカル ワークスペースとサーバー ワークスペースのどちらを使用するかを決定する」(http://msdn.microsoft.com/ja-jp/library/bb892960.aspx)に詳細はありますが、大雑把には
・デフォルトはローカルワークスペース
・ワークスペース内に大量のファイルがある／Visual Studio 2010より前のバージョンを使用するときはサーバーワークスペース
・オフラインで作業することがある場合はローカルワークスペース
ということです。

○ワークスペースのアクセス許可
ワークスペースに対するアクセス許可として
・プライベートワークスペース
・パブリックワークスペース
・パブリックワークスペース（許可）
があります。
デフォルトはプライベートワークスペースですが、１台の端末で複数の開発者（OSログインユーザ）が同じワークスペースを使用する場合はパブリックワークスペースを使用します。
詳細はMSDNの「ワークスペースの作成と操作」(http://msdn.microsoft.com/ja-jp/library/ms181383.aspx)にあります。

次は本題の「ワークスペースをどう作ればいいか」についてです。

「ワークスペースはどう作ればいいの？：前提編」の続きです。
どの単位でワークスペースを作成するかは、「どの単位でソースコードの管理をしたいか？」に依存しますが、以下のような条件により、管理単位が変わると思います。

・端末を共有するか？
　複数の開発者で端末を共有するのであれば、最低限開発者単位でワークスペースは作成しないといけません。そうしないと、別の開発者が変更していたソースファイルをチェックインすることになります。
・複数のプロジェクトを兼任するか？
　変更中のプロジェクトとは別のプロジェクトで変更していたソースコードを間違ってチェックインさせないためには、ワークスペースを分離して作成しないといけません。
・分岐（ブランチ）を使うか？
　変更中の分岐を使用しているときに作業中ではない分岐で変更したソースコードをチェックインさせないためには、ワークスペースを分離する必要があります。

具体例だと、こんな感じになるかと。※あくまで例です。
１．１人の開発者が端末を独占し、関わるプロジェクトは１つだけ。ブランチも切らない。
　　デフォルトで作成されるワークスペース（ローカルワークスペース／プライベートワークスペース、ワークスペース名がコンピュータ名）を使用。

２．１人の開発者が端末を独占し、関わるプロジェクトは複数あるけど。ブランチは切らない。
　　チームプロジェクト毎にワークスペースを作成。（ローカルワークスペース／プライベートワークスペース、ワークスペース名はチームプロジェクト名か、それに関連する名称）

３．１人の開発者が端末を独占し、関わるプロジェクトは複数あり、分岐を使う。
　　チームプロジェクト＋分岐毎にワークスペースを作成。（ローカルワークスペース／プライベートワークスペース、ワークスペース名はチームプロジェクト名か、それに関連する名称＋分岐名）

４．複数の開発者が端末を独占し、関わるプロジェクトは複数あり、分岐を使う。
　　チームプロジェクト＋分岐毎にワークスペースを作成。（ローカルワークスペース／プライベートワークスペース、ワークスペース名はチームプロジェクト名か、それに関連する名称＋分岐名）
　　これだと、３．と同じなので「複数の開発者が同じワークスペース名を使えないんじゃ？」という疑問が湧きますが、「ワークスペースは所有者（OSログインユーザ）毎に管理される」ので、同じワークスペース名でも問題ありません。
　　但し、マッピングするローカルフォルダは開発者ごとに分けないといけません。

通常はこんな感じでいいのですが、これで対処できなかったパターンがあります。
それは、「Visual StudioとEclise(+Team Explorer Everywhere)を両方使用する」場合です。
実際にやってみると、
VS上でチームプロジェクトを作成する
　↓
VS上でチームプロジェクトのルートフォルダを対象にしてワークスペースを作成する
　↓
Eclipse上でチームプロジェクトに接続する
　↓
Eclipse上でチームプロジェクトのルートフォルダを対象にしてワークスペースを作成しようとする
　↓
「（ローカルフォルダは）別のワークスペースで既に使用されている」と怒られる( ;∀;)

という状態です。

ちょっと悩みましたが、どうもIDEが違うと別のワークスペースとしての管理になるっぽいです。
対処としては２パターンあるかと思います。
１．ワークスペースのアクセス許可をパブリックワークスペースに変更
　　同じフォルダを使用することができますが、VSで変更中のソースがEclipse側でも検知されてしまいます。
　　JNI作成のような、C++とJavaの変更を同期を取って作業する場合にはこれでもいいかもしれません。
　　ただ、
　　　・非同期の変更（変更内容が別々）
　　　・TFS上の作業項目に対するチェックイン時関連付けが必須なプロジェクトで、Java側とC++側の作業項目が別々に作成されている
　　ような場合は使いづらいと思います。
　　→VS側でチェックインするときは、Java側の変更対象を除外しないといけない。（逆もそうです）

２．IDEごとに別々のワークスペースを割り当てる
　　通常はこちらが使いやすい気がします。
　　※C++／.NET側とJava側で使用するフォルダをきれいに分ける必要がありますが、普通ごちゃまぜにはしないと思いますので．．．。

ちなみに、「ワークスペース」はTFVC（元々TFSで使用するバージョン管理システム）のみで使用するもので、Gitでは使用しません。
一人で調べものする際はあまり気にしないので、ちょうどいい整理になりました。

（そろそろ仕事場でも分岐は使いたいけど、VB6/VC++6がメインじゃ・・・orz）

やっとここまで来ました。Team Foundation Server 2013のインストールです。

やることは「Tfs_Server.exe /quiet」だけです。
だけなんですが、画面が全く表示されません。インストールが終わったかどうかを確認するためにはタスクマネージャーしかありませんw

ログは「C:\Users\[ユーザ名]\AppData\Local\Temp」にある「dd_tfs_server_[yyyymmddhhmmss].log」に出力されます。
最後に「Exit code: 0x0」とあれば（多分）正常終了です。
ちなみに、GUIでインストールし、キャンセル終了した場合は「0x642」と出力されます。

これで、TFSのインストールまで完了しました。
サーバの構成などは管理コンソールから「画面」で行います。
一度構築した構成を変更するのはコマンドでできるのですが、初期構築をコマンドで行う方法が今のところわかりません。どこかで見つけたときにはまとめたいと思います。

また、PowerShellをうまく使えば、放置状態で最後までインストールできるかもしれません。
（PowerShell勉強不足なもので・・・<(_ _)>）

これでTFS 2013 Update3の環境ができたので、本来の調べものに取り掛かれます。

SharePoint Foundation 2013本体のインストールです。

前々回でイメージを「C:\Temp\Extract」に展開していますので、それを使います。

そろそろ飽きてきそうですが、実行するコマンドは「C:\Temp\Extract\Setup.exe /config [構成ファイル]」です。
詳しくはTechNetの「Config.xml リファレンス (SharePoint Server 2010)」にありますが、引数に指定する構成ファイルのテンプレートは、「C:\Temp\Extract\files」の下に4種類あります。（フォルダ別に格納されています）
今回は「setupfarmsilent\config.xml」をベースにします。
このままでもインストールできるのですが、画面が表示されないと寂しいので、Display要素を以下のように変更します。
<Display Level="basic" CompletionNotice="no" AcceptEURA="Yes" />

あとはsetupコマンドを実行するだけです。

次は、Team Foundation Server 2013のインストールです。

SQL Server 2014のインストールです。

基本的には「Setup.exe
/ConfigurationFile=[構成ファイル名]」で終了です。

問題は、引数に指定されている構成ファイル(ConfigurationFile.ini)をどう作成するかです。
MSDNの「コマンド プロンプトからの SQL Server 2014 のインストール」「
構成ファイルを使用した SQL Server 2014 のインストール」に記載がありますが、一番簡単に作成する方法は、「SQL Serverのインストールウィザードを途中まで実行してしまう」ことです。
ウィザードに従ってインストール画面を進めると、インストール内容の確認画面が表示されますが、この画面の下側に「構成ファイルのパス」という項目があります。
このファイルをコピーして、少しだけ項目を変更すれば簡単に構成ファイルが作成できます。

作成した構成ファイルに、以下の変更をします。
☆追加する項目
○SQL Serverエージェントサービスアカウントのパスワード
　AGTSVCPASSWORD="～"
○Analysis Servicesサービスアカウントのパスワード
　ASSVCPASSWORD="～"
○SQL Serverサービスアカウントのパスワード
　SQLSVCPASSWORD="～"
○Reporting Servicesサービスアカウントのパスワード
　RSSVCPASSWORD="～"
○ライセンス条項への同意をするか（=1：同意する）
　IACCEPTSQLSERVERLICENSETERMS="1"
○プロダクトキー
　PID="～"

☆変更する項目
○UIを使用して実行＋入力不可＋エラーメッセージを表示しない（コマンドライン引数の「/QS」）
　QUIETSIMPLE="True"

☆コメントアウトする項目
　UIMODE=～
　QUIET=～
　→「QUIETSIMPLE」と排他で使用する項目のため。

画面でパラメータファイルが作成できるのはいいですね。
次はSharePoint Foundation 2013のインストールです。

＜参考＞構成ファイルの例
;SQL Server 2014 Configuration File
[OPTIONS]

; INSTALL、UNINSTALL、UPGRADE などのセットアップ ワークフローを指定します。これは必須のパラメーターです。

ACTION="Install"

; ローカライズ版の Windows オペレーティング システムに英語版の SQL Server をインストールするには、/ENU パラメーターを使用します。

ENU="False"

; ユーザー インターフェイスの動作を制御するパラメーターです。有効な値は Normal (完全な UI の場合)、AutoAdvance (簡易 UI の場合)、および EnableUIOnServerCore (GUI ブロックをバイパスする Server Core セットアップの場合) です。

;UIMODE="Normal"

; ユーザー インターフェイスは表示されません。

;QUIET="False"

; ユーザー操作はなく、進行状況だけが表示されます。

;QUIETSIMPLE="False"
QUIETSIMPLE="True"

; SQL Server セットアップで更新プログラムを検出して含める必要があるかどうかを指定します。有効な値は、True と False または 1 と 0 です。既定では、SQL Server セットアップには、検出された更新プログラムが含まれます。

UpdateEnabled="False"

; 今後のリリースの SQL Server の改善のため、Microsoft にエラーを報告できるようにするかどうかを指定します。この機能を有効にするには 1 または True を指定し、無効にするには 0 または False を指定します。

ERRORREPORTING="False"

; このパラメーターが指定された場合、このコンピューターでは Microsoft Update を使用して更新プログラムが確認されます。

USEMICROSOFTUPDATE="False"

; インストール、アンインストール、またはアップグレードを行う機能を指定します。最上位の機能には、SQL、AS、RS、IS、MDS、ツールなどがあります。SQL 機能では、データベース エンジン、レプリケーション、フルテキスト、および Data Quality Services (DQS) サーバーがインストールされます。ツール機能では、管理ツール、オンライン ブック コンポーネント、SQL Server Data Tools、その他の共有コンポーネントがインストールされます。

FEATURES=SQLENGINE,FULLTEXT,AS,RS,SSMS,ADV_SSMS

; SQL Server セットアップが更新プログラムを取得する場所を指定します。有効な値は、"MU" (Microsoft Update を検索)、有効なフォルダー パス、.\MyUpdates のような相対パス、または UNC 共有です。既定では、SQL Server セットアップは Microsoft Update を検索するか、Window Server Update Services を通じて Windows Update サービスを検索します。

UpdateSource="MU"

; コマンド ライン パラメーターの使用方法を表示します

HELP="False"

; 詳細なセットアップ ログをコンソールにパイプすることを指定します。

INDICATEPROGRESS="False"

; セットアップで WOW64 にインストールするよう指定します。このコマンド ライン引数は、IA64 や 32 ビット システム上ではサポートされません。

X86="False"

; 共有コンポーネントのルート インストール ディレクトリを指定します。このディレクトリは、共有コンポーネントのインストール後は変更されません。

INSTALLSHAREDDIR="C:\Program Files\Microsoft SQL Server"

; WOW64 共有コンポーネントのルート インストール ディレクトリを指定します。このディレクトリは、WOW64 共有コンポーネントのインストール後は変更されません。

INSTALLSHAREDWOWDIR="C:\Program Files (x86)\Microsoft SQL Server"

; 既定のインスタンスまたは名前付きインスタンスを指定します。既定のインスタンスは、Express 以外のエディションの場合は MSSQLSERVER、Express エディションの場合は SQLExpress です。SQL Server データベース エンジン (SQL)、Analysis Services (AS)、または Reporting Services (RS) のインストール時には、このパラメーターが必須です。

INSTANCENAME="MSSQLSERVER"

; SQL Server 機能の使用状況データを収集して Microsoft へ送信できるようにするかどうかを指定します。この機能を有効にするには 1 または True を指定し、無効にするには 0 または False を指定します。

SQMREPORTING="False"

; 指定した SQL Server 機能のインスタンス ID を指定してください。SQL Server のディレクトリ構造、レジストリ構造、およびサービス名には、SQL Server インスタンスのインスタンス ID が組み込まれます。

INSTANCEID="MSSQLSERVER"

; RSInputSettings_RSInstallMode_Description

RSINSTALLMODE="DefaultNativeMode"

; インストール ディレクトリを指定します。

INSTANCEDIR="C:\Program Files\Microsoft SQL Server"

; エージェント アカウント名

AGTSVCACCOUNT="TFS2013\TFSService"

; インストール後にサービスを自動的に開始します。

AGTSVCSTARTUPTYPE="Manual"

; Analysis Services サービスが実行されるアカウントの名前。

ASSVCACCOUNT="TFS2013\TFSService"

; サービスが作成された後に、サービスのスタートアップの種類に関する設定を制御します。

ASSVCSTARTUPTYPE="Automatic"

; Analysis Services で使用される照合順序。

ASCOLLATION="Japanese_CI_AS"

; Analysis Services のデータ ファイルの場所。

ASDATADIR="C:\Program Files\Microsoft SQL Server\MSAS12.MSSQLSERVER\OLAP\Data"

; Analysis Services のログ ファイルの場所。

ASLOGDIR="C:\Program Files\Microsoft SQL Server\MSAS12.MSSQLSERVER\OLAP\Log"

; Analysis Services のバックアップ ファイルの場所。

ASBACKUPDIR="C:\Program Files\Microsoft SQL Server\MSAS12.MSSQLSERVER\OLAP\Backup"

; Analysis Services の一時ファイルの場所。

ASTEMPDIR="C:\Program Files\Microsoft SQL Server\MSAS12.MSSQLSERVER\OLAP\Temp"

; Analysis Services の構成ファイルの場所。

ASCONFIGDIR="C:\Program Files\Microsoft SQL Server\MSAS12.MSSQLSERVER\OLAP\Config"

; MSOLAP プロバイダーがプロセスで実行可能かどうかを指定します。

ASPROVIDERMSOLAP="1"

; 準備する必要のある管理者アカウントの一覧を指定します。

ASSYSADMINACCOUNTS="TFS2013\Administrator" "TFS2013\TFSAdmin"

; Analysis Services インスタンスのサーバー モードを指定します。有効な値は MULTIDIMENSIONAL と TABULAR です。既定値は MULTIDIMENSIONAL です。

ASSERVERMODE="MULTIDIMENSIONAL"

; CM ブリックの TCP 通信ポート

COMMFABRICPORT="0"

; マトリックスでのプライベート ネットワークの使用方法

COMMFABRICNETWORKLEVEL="0"

; ブリック間の通信を保護する方法

COMMFABRICENCRYPTION="0"

; CM ブリックで使用される TCP ポート

MATRIXCMBRICKCOMMPORT="0"

; SQL Server サービスのスタートアップの種類。

SQLSVCSTARTUPTYPE="Automatic"

; FILESTREAM 機能を有効にするレベル (0、1、2、または 3)。

FILESTREAMLEVEL="0"

; SQL Server Express で RANU を有効にするには、"1" に設定します。

ENABLERANU="False"

; データベース エンジンに使用する Windows 照合順序または SQL 照合順序を指定します。

SQLCOLLATION="Japanese_CI_AS"

; SQL Server サービスのアカウント: ドメイン\ユーザーまたはシステム アカウント。

SQLSVCACCOUNT="TFS2013\TFSService"

; SQL Server のシステム管理者として準備する Windows アカウント。

SQLSYSADMINACCOUNTS="TFS2013\Administrator" "TFS2013\TFSAdmin"

; 現在のユーザーを %SQL_PRODUCT_SHORT_NAME% Express のデータベース エンジン システム管理者として準備します。

ADDCURRENTUSERASSQLADMIN="False"

; TCP/IP プロトコルを無効にするには 0 を、有効にするには 1 を指定します。

TCPENABLED="1"

; Named Pipes プロトコルを無効にするには 0 を、有効にするには 1 を指定します。

NPENABLED="0"

; Browser サービスのスタートアップの種類。

BROWSERSVCSTARTUPTYPE="Disabled"

; レポート サーバーの NT サービスが実行されるアカウントを指定します。省略した場合または値が空の文字列の場合は、現在のオペレーティング システムの既定のビルトイン アカウントです。
; RSSVCACCOUNT のユーザー名部分は最大 20 文字です。
; RSSVCACCOUNT のドメイン部分は最大 254 文字です。

RSSVCACCOUNT="TFS2013\TFSService"

; レポート サーバーの NT サービスのスタートアップ モードを指定します。
; Manual – サービスのスタートアップは手動モードです (既定値)。
; Automatic – サービスのスタートアップは自動モードです。
; Disabled – サービスは無効です。

RSSVCSTARTUPTYPE="Automatic"

; 入力引数 FTSVCACCOUNT の説明を追加します

FTSVCACCOUNT="NT Service\MSSQLFDLauncher"

AGTSVCPASSWORD="TFSService"
ASSVCPASSWORD="TFSService"
SQLSVCPASSWORD="TFSService"
RSSVCPASSWORD="TFSService"
IACCEPTSQLSERVERLICENSETERMS="1"
PID="～"