こんにちは、同僚。
長い休暇が終わり、明日、私たちは再び日常の深ofに突入します。 今日、まだ終わっていない休日とまだ始まっていない週の合流点で、
継続的な統合について少しお話ししたいと思います。
開発でアジャイルプラクティスの実装を開始し、多くの人が「プロセスとツールよりもパーソナリティとその相互作用が重要」と読んで喜んでいます。 結局のところ、チームを編成し、それらを結集し、タスクを設定することができます。ここでは、「魅惑的な幸福の星」（仕事をし、ソフトウェアユーザーに役立つ）です。 しかし、残念ながら、人生ではすべてがはるかに退屈で予測不可能です。 新しいフラムスクラムまたはかんばんを導入し始めて、彼らはしばしば、これらの技術のすべての利点が正しいエンジニアリングプラクティスに当てはまる場合にのみ現れることを忘れています。 これらのプラクティスには、一般的なユニットテスト、特にTDDが含まれます。 ペアプログラミング; コードレビュー; 継続的な統合など。
カットの下で、TFS 11内で継続的統合を構成する方法と、どのシナリオ、どのプロジェクトの構築方法が最も正当化されるかを示します（多くの写真とテキスト）。
そのため、メインコンテンツの前に、記事で以下で説明するすべてを繰り返すために必要なことについていくつかの言葉を紹介します。
1. TFS 11をインストールしました
2. Visual Studio 11または2010。
TFS 11およびVS 11は、
Microsoft Webサイトからダウンロードできます。
TFS 11がなく、TFS 2010があり、ユーザーインターフェイスに違いがある場合、記事に記載されているすべてを構成できます。
Team Foundation Build Serviceのセットアップ
ビルドサービスが既に構成されている場合
は、記事の2番目の部分に直接進んで
ください 。
TFS管理コンソールを起動して[ビルド構成]を選択すると、次のプロンプトが表示されます。
設定可能！ ウィザードは非常にシンプルで、最初の画面をすぐにスキップしますNext：
2番目のステップでは、カスタムビルドサービスが機能するプロジェクトのコレクションとTFSサーバーを指定する必要があります。 デフォルトでは、現在のTFSサーバーの最初のコレクションが選択されます。
3番目のステップでは、このサーバー内の建物にサービスを提供するエージェント数を決定する必要があります。 1を選択すると、すべてのアセンブリ要求がキューに入れられ、1つのプロジェクトをコンパイルした後、キューからの次の要求がコンパイルを開始します。 このアプローチの主な利点は、サーバーの負荷を減らすことです。マイナス-プロジェクトが長時間コンパイルされ、キューが大きい場合、待機する必要があります。 ビルドエージェントの数が増えると、キューの処理が高速になります。主なことは、膨大な数の場合、サーバーがコンパイルよりもエージェント間の切り替えに多くの時間を費やさないことです。
最後の画面で、ビルドサービスを実行するために必要な資格情報を指定するよう求められます。 テスト環境や実稼働環境にデプロイせずにプロジェクトのみをコンパイルする場合は、デフォルト値のままにすることもできます。 それ以外の場合、ビルドサービスのアカウントの選択では、これらのタスクを実行するためにアカウントに必要な権限を考慮する必要があります。
実際には、構成はここで終了します。 さらに2つの画面があり、選択したものと、選択したものを構成できるかどうかを確認します。 [準備チェックで構成]をクリックし、構成が完了するのを待つと、次のように表示されます。
一貫してこの場所に到達している場合、TFS管理コンソールのビルド構成は次のようになります。
ここで、Team Foundation Server管理コンソールでの作業を終了し、Visual Studioに切り替えることができます。
デモンストレーション環境
わかりやすくするために、ソース管理に配置する必要がある単純なWPFアプリケーションを取り上げます。 また、最初のプロジェクトの機能をテストする単体テストを含むプロジェクトを追加します。
この記事のTFSのフォルダー構造は次のとおりです。
はい、忘れるまで、ネットワークフォルダーは、ビルドされたソリューションが追加されるフォルダーとして機能する必要があります。 ビルドサービスを実行しているアカウントにはアクセス権が必要です。
1.ソリューションを構築するための手動リクエスト
すぐに予約、手動での起動、継続的な統合を行います。これらはさまざまなおとぎ話のコンセプトです。 継続的インテグレーションには、人間の介入なしに、プロジェクトを自動的に定期的に構築することが含まれます。 しかし、なぜなら 手動でのビルドリクエストは最も単純であり、他のすべての起動ケースのセットアップは手動でのリクエストを非常に連想させるので、それから始めましょう。
シナリオ：開発中のブランチがあります。 また、運用環境に展開されるプロジェクトのバージョンを保存するブランチがあります。 時々、作業バージョンにバグがあります。 対応するプロジェクトをダウンロードし、エラーを修正し、開発者のローカルコンピューターで確認し、ソース管理に配置します。 テスターや展開スペシャリストは、このソリューションを構築する必要があります。 これを行うために、彼らは手動リクエストを実行します。
セットアップ：チームエクスプローラーのホームページで、[ビルド]を選択し、[新しいビルド定義]タブが開きます：
新しいビルド定義を作成するためのウィザードの最初のステップでは、このビルド要求をさらに識別するための名前を指定する必要があります。 この例では、デフォルト名にサフィックス「_manual」を追加しました。
2番目のステップでは、ビルドエージェントをアクティブにする必要があるタイミングを設定し、ビルドを開始できます。 Manualのデフォルト値で十分です：
3番目の手順では、ソース管理のソリューションフォルダーの場所とサーバー上のビルドエージェントの場所を指定できます。 ほとんどの場合、これらの値はデフォルトで残すことができます。
4番目のステップでは、ビルドするコントローラーと、出力プロジェクトを配置するフォルダー（ステージング場所）を指定できます。 さらに、プロジェクトをビルドし、その上ですべての単体テストを実行し、結果のexeおよびdllが必要ない場合は、最初の配置オプション（ファイルを出力フォルダーにコピーしない）が正当化されます。 3番目のオプション（ビルドの結果をソース管理に配置する）は、安定したビルドを失わないという目的で、開発者にとって便利な場合があります。 しかし、基本的に、もちろん、構築結果がネットワークフォルダーにコピーされるときに2番目のオプションが適用されます。 さらに、ビルド定義の起動ごとに、サブフォルダーが作成され、デフォルトでは、すべてのビルドがスキームに従って保存されます：<プロジェクト名> _ <ビルド日付>。<ビルド日付のビルド番号>。
最後から2番目のステップでは、一般的なビルド設定を設定します。 デフォルトでは、open slnがすぐに選択され、ユニットテストを実行する価値があることに注意してください。
ただし、もちろん、ビルドモードは変更できます。 たとえば、プロジェクトをコンパイルする構成の変更：
ツールバーの「保存」ボタンを使用して、ビルド定義を保存します。 チームエクスプローラーには、新しいビルド定義があります。
起動するには、そのコンテキストメニューを開き、[新しいビルドをキューに追加...]を選択します。 開いたウィンドウで、「キュー」をクリックします。 そして、私たちは構築中であることを確認し、最後に、ピクトグラムは構築の結果について教えてくれます：
構造をダブルクリックすると、ユニットテストの結果を含む詳細情報を表示できます。
すべて、手動で開始し、基本的なクエリで、私は終了します。 残りのシナリオを簡単に見ていきましょう。
2.ソース管理の各コード配置のソリューションを構築する
シナリオ：開発者はコード、ユニットテストを記述します。 これらすべてをコードリポジトリに配置します。 これがすべて正常に行われ、すべてのテストに合格することを確認する必要があります。
設定：新しいビルド定義のセットアップは、ウィザードの最初のステップ（別の名前を指定する必要があります）と2番目のステップでのみ異なります。 トリガーとして、2番目のオプションを指定します。
ビルドを開始するには、プロジェクトまたは単体テストのコードを変更し、ソース管理に変更を配置します。 チェックインの最後に、チームエクスプローラーパネルの[ビルド]タブに移動すると、ビルドが実行中であることがすぐにわかります。 ところで、合格しなかった新しいテストをプロジェクトに追加しました。
また、この構造の詳細を発見し、何がうまくいかなかったかを分析することもできます。
この構築シナリオでは、重大な欠点があります。 多くの開発者がいて、TDD（頻繁なチェックイン）に取り組んでおり、プロジェクトの構築とテストの完全な実行に5〜10分かかる場合、1つのビルドエージェントを含むビルドキューは非常に長くなり、ソース管理に変更を配置するのに長い時間待つ必要があります建設の結果。
3.チェックインでビルドしますが、それより頻繁ではありません...
シナリオ：シナリオはオプション2と同じですが、TFSサーバーはそれに対処せず、マニュアルは別のビルドサーバーにお金を与えません。
セットアップ：同様に手動で、2番目のステップで3番目の構築オプションを選択します。
前の段落「チェックイン」で追加されたテストに合格するようにプロジェクトを修正します。 そして、すぐに2つのビルドを開始したことがわかります。 各チェックインで実行する必要があるものと、Ckeck-Insで実行する必要があるもの、ただし1時間に1回以下（構築がキューにあることを示すアイコンに注意してください）：
確かに、次のチェックインでは、60分後よりも早く発生した場合、新しいビルドは開始されません。
これら2種類のビルドを使用すると、たとえば、テストを実行せずに各チェックインのプロジェクトをビルドし、テストを実行して少なくとも1時間に1回ビルドできます。
4.コンパイルしない場合、ソース管理にコードを配置できません
シナリオ：あなたのチームには、ソース管理にコードを入れる前にチェックするのを忘れている新しい開発者がいますが、それでもコンパイルしますか？
セットアップ：新しいビルド定義を作成して名前を付け、トリガーのオプション4を選択してビルドを開始します。
コードを変更し（単独でコンパイルを停止するように）、チェックインしようとすると、次の通知が表示されます。
そして、コンパイルを開始した後、チームエクスプローラーは、ビルドが完了するまで待つ必要があることを明確に思い出させます。コンパイルが完了すると、通知がポップアップ表示されます。
便利な、いまいましい！
5.毎日のビルド
シナリオ：まだ毎日ビルドがないのはどうしてですか？ その後、Joel Spolskyテストの第3段落（http://russian.joelonsoftware.com/Articles/TheJoelTest.html）を早急に読んでください。
セットアップ：さて、あなたはおそらく既に知っています、新しいビルド定義を作成し、名前を変更し、2番目のステップでコンパイルする日と時間を設定します：
すべて、毎晩、邪悪なビルドエージェントが来て、コンパイル、コンパイル、コンパイルします。
結論の代わりに
継続的な統合のない世界にまだ住んでいますか？ はいの場合、それは無駄です！
ご覧のとおり、セットアップにはそれほど時間はかかりませんが、プロジェクトが定期的にコンパイルされたり、単体テストが行われたりするなどの結果は、ほとんどすぐに感じられます。
そして最後に、VSデザインの新しいバージョンが気に入っています。 すべてが非常に便利で明確です：
