ビルド-デプロイ-テスト。 継続的インテグレーション

継続的インテグレーション （Eng。継続的インテグレーション、以下CIと呼びます）は、ソフトウェア開発の実践であり、プロジェクトの頻繁な自動アセンブリを実行して、複数の開発者の結果を統合する問題を迅速に特定して解決します。



これは方法論や標準ではなく、実践であり、すべてのチームメンバーの継続的な作業と関与を意味します。 なんで？ はい、統合のためのプロジェクトの終わりと突然の世界的な崩壊を待たないように。 さらに、CIのタスクは、リファクタリング、壊滅的な変更、新しい機能の追加、アーキテクチャの変更、その他の予期しない問題や既知の問題から保護することです。



統合アセンブリの助けを借りて、「わからない、すべてがマシンで動作する」シンドロームを取り除くことができます。 また、「不正なコード」、頻繁に繰り返されるバグ、「不正な」合併から身を守ります。 CIは、日中にプロジェクトのステータスを監視できるため、フィードバックの可能性が高まります。



連続性に至った経緯



当社は、さまざまな最新のテクノロジーであるSOAを使用して、新しい大規模な.NET小売プロジェクトを開始しました。 開発はコンポーネント間で徐々に統合され、完全にゼロから実行されました。 コンポーネントの開発とテストは 、さまざまな大陸で行われました。



コアのサービスコンポーネントを開発しました。 さらに、コンポーネントのパフォーマンスとインストールと削除をテストする必要がありました。 また、開発要件もありました-単体テストによる100％のコードカバレッジ。 その結果、自動テスト、単体テスト、4つのテスト環境、部分的に実装されたコンポーネント、「落ちる」アセンブリとバグ（それらがない場合）、および14人の開発者用の1つのテスターがあります。 しかし、私はすべてを組み立て、インストール、テスト、および削除したいと考えています。 そして、もちろん、最も安定した高品質の結果をメインのテストチームに提供したいのです。



チームに15人しかいない場合、4つのシステムで1つをテストするのは簡単ではありません。 したがって、 MicrosoftのアプローチであるBuild-Deploy-Testを試すことにしました。 また、次のツールは、テスターが開発に追いつくのに役立ちました：TFS 2012、MSTest Manager 2012、Visual Studio 2012 Ultimate。 時間が経つにつれて、2013年に切り替えました。



JenkinsとTFS serverの 2つのCIサーバーを作成することにしました。 最初は、デバッグモード（デバッグモード）で1時間ごとにすべてが行われていました。 その後、サーバーへのインストールが行われ、スモークテストが実行され（アプリケーションが開始されていることをテストする）、その後アンインストールが開始されました。 Sonarは、1日に1回、夜間にすべてのユニットおよび統合テストを実行しました。 これにより、アセンブリが不安定になり、開発者が問題について早期に警告することで問題が解決しました。 2番目のCIサーバー（TFSビルドサーバー）では、デバッグモードでもアセンブリが実行されました。 その後、テストマシンへのインストールと機能的な自動テストの起動が実行されました。 すべてのテストが完了した後（成功したかどうかは関係ありません）、アンインストールが行われました。



開発者テスト（ユニットと統合）をテスターの機能テストから分離するために、2つのCIサーバーを作成することにしました。 Jenkinsでのビルドは、落下テストにすぐに対応するためにはるかに頻繁に行われました。 また、機能テストの全サイクルには多くの時間がかかるため、必要に応じて夜間に毎日、TFSでのアセンブリがテスターに​​よって実行されました。 さらに、すべてがリリース構成でビルドされ、少なくともコードが常にコンパイルされるように、Gated Check-inアセンブリを導入しました。 プログラマーまたはテスターが変更をTFSにアップロードすると、システム全体が最初にリリース構成でアセンブルされ、変更が成功した場合にのみ変更がTFSに反映されます。 問題がある場合、変更は適用されず、TFSのアセンブリは機能し続けます。



機能テストの自動化を開始し、タイプを選択しました。 マイクロソフトは以下を提供します。

• プログラマーによって書かれた単体テスト 。
• コード化されたUiテスト -機能テストとユーザーインターフェイステストを自動化するように設計されたテストの一種。
• Webパフォーマンステスト -負荷テスト（負荷テスト）の編成の一部としてのWebアプリケーションの機能テスト。
• 負荷テスト -Webアプリケーションの負荷テストを実施するためのテスト。
• 汎用テストは、外部のテストアプリケーションを実行できる特別なタイプのテストです。
• 順序付きテスト -すべての記述された自動テストの実行を特定の順序で整理できます。

その結果、熟考の結果、 一般的な テストと順序付けられたテストの方が適していると判断しました。



Genericテストでは、* .exeファイルと、フィードする必要のあるパラメーターを指定する必要があります。 TFSの各テストケースは、一般的なテストに関連付けられていました。 自動テストの場合、コンポーネントごとに1つのプロジェクトがあり、TMから自動テストを実行すると、一般的なテストが呼び出され、現在の自動テストの番号が目的の* .exeファイルに転送され、必要なメソッドが実行されます。



Build-Deploy-Testプロセス全体は次のとおりです。開発者は変更を行い、変更をアップロードする前に、Build Serverはリリース構成のすべてを収集し、アセンブリが合格すると、変更がサーバーにアップロードされます。







機能テストの詳細。



Build-Deploy-Testアプローチによると、ビルドコントローラー（BC） 、 テストコントローラー（TC） 、 テストエージェント（TA）の 3つの役割があります。 ビルドコントローラーは、ビルドサーバーおよびテストコントローラーと同じです。



ビルドコントローラーはプロジェクトのビルドを監視し、バイナリをビルドフォルダーに収集します（ここでは、Gated Check Inは適切ではありません。テスト用に個別のビルド構成がありました）。 テストコントローラーは、起動の管理、テスト結果の保存に必要です。 そして、テストエージェントは、テストスイートの起動に関するコマンド、展開コマンド、および一連の汎用テストを含むすべての起動パラメーターをTSから受け取ります。



テスターはMicrosoft Test Managerを開き、必要なテスト計画、実行する構成、使用するアセンブリ、およびテスト環境を選択します。 それだけです！ 残りはテストコントローラーによって行われます。 テスト実行用の一連のパラメーター（バイナリフォルダーの場所を含む）を受け取り、テスト環境でインストールを開始します。 インストールスクリプトが完了すると、テストエージェントは選択されたすべてのテストを1つずつ実行します。 すべてのテストが完了すると、クリーニングスクリプトが起動され、アプリケーションが削除され、テストシステムがクリーンアップされて、初期状態に戻ります。 次に、テストエージェントはテストコントローラーに制御を移し、テストコントローラーに準備ができたことを伝えます。 テストコントローラーは、テスト実行のすべての一時フォルダーを取得し、結果をTFSに入れ（TMで確認できます）、テスト結果をTMで表示します。



テスト環境の設定



すべてのアセンブリはビルドサーバーに保存されます。 汎用テストもそこにあります。 Microsoft Test Manager（TM）で自動テストを実行した後、テストコントローラーはテストマシン上に一時フォルダーを作成します。ここに汎用テストをコピーし、deploy.batおよびclean.batファイルを作成します。 これらのスクリプトは2つの部分で構成されています。 最初の部分は、ビルドディレクトリの名前を含むすべてのスタートアップ変数の定義です。2番目の部分は、これらのテスト設定に指定したデプロイファイルの内容です。



したがって、TCがスクリプトのラッパーを作成し、スクリプトの展開方法を教えたことがわかりました（Call Deployスクリプトと呼びましょう）。







私たちの場合、このスクリプトはビルドディレクトリ全体をテストマシンにコピーしてから、別のインストールスクリプト（このビルドにあったデプロイスクリプト）を呼び出します。 これは、ビルドで更新できるように、展開スクリプトにバージョン管理を持たせるために必要です。



すべてのスクリプトは同じ環境に実装されているため、このスクリプトはすでにインストールのすべての準備を実行し、TCから渡された変数にアクセスできます。 これらを使用して、スクリプトは構成を更新し、アプリケーションをインストールします。 展開が完了すると、テストコントローラーが動作を開始し、テストエージェントがテスト（一時フォルダーにコピーしたものと同じ汎用テスト）を実行するタスクを提供します。 これらの汎用テストは、指定されたパスで* .exeファイルを呼び出し、テストケース番号をパラメーターとしてプログラムに渡します。 自動テストは、渡されたパラメーターに応じて特定のメソッドを呼び出します。



すべてのセルフテストが完了すると、テストコントローラーはクリーニングプロセスを開始します。 これを行うために、彼は最初に作成したスクリプトラッパーを呼び出します。 パラメーターを決定し、すべてのテストシステムにあるCall Cleanスクリプトを呼び出します。 Cleanを呼び出すと、Cleanスクリプトが実行され、アプリケーションがアンインストールされ、すべてのログが収集されてアーカイブされ、テストコントローラーによって作成された一時的なスタートアップフォルダーに移動されます。これにより、クリーニングプロセス後にすべてのログがTFSに読み込まれ、テストを実行するために接続されます。



Build-Deploy-Testアプローチを開始するようにスケジュールされたビルドがあります。 このため、特別なプロセステンプレートがアセンブリ定義で指定されています。 週に一度、そのようなアセンブリが開始されます。 その設定は、どのテストを実行する必要があるか、どの設定で、どのテスト環境で選択したテストを実行する必要があるかを示します。



プロセス全体は、ビルドコントローラーから開始し、ビルドエージェントにビルドのパラメーター（ビルドするプロジェクト、リリース/デバッグがある構成）を提供します。ビルドエージェントがすべてを収集した後、ビルドコントローラーはテストコントローラーに制御を移します。自動テストを実行するためのパラメーターは、一連の自動テスト、テスト環境、およびテスト設定です。



弊社では、テスト環境ごとに、独自のテスト設定と独自のアセンブリを使用しています。



テストコントローラーを開始した後、展開プロセスを開始し、テストエージェントにテストを渡し、その後、テストコントローラーがシステムクリーニングスクリプトを実行します。



テスト環境が2台のマシンで構成されている場合、これはTest Managerで指定する必要があります。テスト環境は1つ作成され、2台のマシンが存在します。 各マシンにはTFSに接続された独自のテストエージェントがあるため、これらのマシンはTMで表示されます。 各マシンには、データベースサーバーとクライアントなど、個別のロールが割り当てられます。







この場合、起動時に同じことが発生しますが、テスト環境は2台のマシンで構成され、テストは1台のマシンでのみ実行されます。ログは、役割によって異なる方法で収集することもできます。



Build-Test-Deployプロセスの構成に関する問題



判明したように、PowerShellスクリプトはデプロイ/クリーンスクリプトには適していません。cmdまたはbatのみがそれらに適しています。 また、バッチファイルを使用するように設定し、バッチファイルからPowerShellスクリプトを呼び出すと、Test Managerはこの呼び出しを無視します。 同様に、タイマーを使用して存在しないホストのすべてのスリープ、待機、およびpingを無視します（サービスの停止/開始後にスリープが必要でした）。 そのような単純なことでも、バッチファイルから起動された松葉杖を個別に作成する必要がありました。



プロジェクトが発展するにつれて、テストも進化しました。 最初はライブラリのセットであったため、それらをコピーして展開スクリプトでテストを実行し、その後削除するだけでした。 そして誰もが幸せでした。 その後、私たちの勇敢な開発者は、多くのパラメーターで実行する必要があるmsiパッケージですべてをラップしました。 それに応じて削除します。 ここでは、送信する必要のあるパラメーターの変更により、タスクがより複雑になりました。 このために、テストコントローラーがテストエージェントに送信するパラメーターを使用しました。 それで十分でした。



次に、多くのmsiインストールパッケージが来ました。これは、特定の順序で、多くのパラメーターと構成ファイルと共にインストールする必要があります。 テストシステムに応じて構成を実行するために、すべての接続文字列をデフォルトの文字列から目的の文字列に置き換え、すべてのパス、パラメーターなどを置き換えました（これはすべて、自動テストのスタートアップパラメーターからも取得されました）。 それでも、MSMQ（Microsoft Message Queuing）キューを削除する必要がありました。 単純なバトニックではこの問題を解決できないため、PSでこのようなスクリプトを作成しました。 しかし、その後、別の驚きが待っていました-MicroSoft Test Managerは、その輝かしいPowerShellで動作することを望んでいません。 理由は明らかではありません。 その結果、これも自動テスト自体で決定されました。



最終的な（現時点での）インストール段階は、必要なコンポーネントとパラメーターが選択され、パラメーター付きの必要なインストーラーファイルをすべて起動するユーザーインターフェイスを備えた1つのプログラムでした。 同様に削除します。 ユーザーインターフェイスで値を設定することなく、インストールを自動化しました。 インストーラーには、インストールおよびアンインストールに必要なパラメーター（テストコントローラーから転送できる部分的に使用されるパラメーター）が設定されたxmlファイルが表示されます。 他のすべては同じように起こります。



そのため、プロセス全体を自動化して設定しました。 もちろん、継続的な統合を実現する手段は、プロジェクト、企業の好み、伝統、ポリシーとは大きく異なる可能性があります。 そして、私たちはあなたがあなたの会社に必要なものを決めるのを助けることができます。



著者rsarvarova