Windows PhoneとTeamCityの継続的な統合

Team CityでWindows Phone 7プロジェクトの継続的統合システムをセットアップした経験を共有したいと思います。 同じ道を行く人、私が費やした時間、神経を救うことを願っています。



与えられた：

1. Silverlight Toolkitを使用して実装された単体テストを備えたかなり大規模なWindows Phone 7アプリケーション。
2. 単体テストを実行せずに、TeamCityでカスタマイズされたアプリケーションのビルド。 ビルドエージェントは「物理的な」（ある意味では、仮想ではない）マシンです。

必要です：

1. VMWareの下の仮想マシンに別のTeamCityビルドエージェントをセットアップします。
2. アセンブリ中にユニットテストを実行し、実行結果をTeamCity統計に収集します。

ビルドエージェントのセットアップ

Windows Server 2008 R2を搭載した仮想マシンは、ビルドエージェントとして使用されます。 最初は、セットアップは簡単に見えました-Visual Studio、Windows Phone SDK、およびエージェント自体をインストールします（エージェントはデプロイされたTeamCityのサイトから直接ダウンロードされます）。 Silverlightなしのテストプロジェクトは問題なく「開始」されました。ユニットテストはすぐに混乱し、組み込みのTeamCity dotCoverを使用してコードカバレッジを制御できるようになりました。



ゼロから5分でこのような結果を得ることができて良かったです！

エミュレーターの起動

火がついたので、Windows Phoneのアセンブリの立ち上げを始めました。 ここから楽しみが始まりました。

TeamCityでは、アセンブリが既に構成されているため、データを準備するために特定のコードを実行する必要があったと言わなければなりません。 このコードは「ライブ」アプリケーションで使用されており、Silverlightランタイムから切り離すのが面倒でした。 したがって、アセンブリ中に、TeamCityエージェントによって呼び出されるエミュレーターでコードが実行されました。 このようなスキームは、既存のビルドエージェントで機能しました。

ただし、新しいビルドエージェントで同様のアセンブリをセットアップすることは、数日後に主に悪用でいっぱいになりました。 私が捕まえた主なショールは次のとおりです。

• Windows Phone SDKがインストールされていません-サーバーOSを認識せずにWindows 7が必要だと不満を言いました。 GoogleとMSDNが支援しました。 SDKを完全にダウンロードしたので、指示に従ってbaseline.datを編集した後、キーなしでsetup.exeを実行し、すべてが正常にインストールされました。
• Windows Media Playerがインストールされていないため、エミュレータは起動しませんでした。 Windows Server 2008にインストールすることも非常に直感的ではありませんでした。
• 彼らは 、エミュレーターが特定のフラグと手動（！）仮想マシンの構成を編集しないと起動しないかもしれないと言いますが、これは私をパスしました。 Windows Phone 7エミュレーターが必要で、タンバリンとのダンスがWindows Phone 8エミュレーターについて説明されているためか、管理者は仮想マシンの設定が「すべてを含む」ことを保証したのでしょう。
• エミュレータは、仮想マシンのRAMボリュームが1 GBから2 GBに増加するまで起動しませんでした。 それは静かに開始しませんでした-理由のヒントではありません！

ところで、SDKのインストール時に作成されたショートカットを使用すると、エミュレータが起動しません。 管理ユーティリティから呼び出すと、正常に起動するため、理由はわかりませんでした。



エミュレータが最終的に起動したときに、最後に最大の問題が表面化しました。 起動時のエミュレータは、通常の操作には通常のビデオカードが必要であると警告しましたが、仮想マシンに「転送」するには機能しませんでした。 このような恐るべき警告の後、エミュレーターは正常に動作したという事実にもかかわらず、誰かがOKボタンを押す必要がありました。 エミュレータはTeamCityエージェントサービスによって起動され、画面に表示されないと想定されていたため、ボタンを押す人はいませんでした。

必死の試みで、私はこの不運なボタンを押すようにコーディングしようとしましたが、エージェントサービスからエミュレーターを起動するときにこれは機能しませんでした。

私が思いついた唯一のことは、ビルドエージェントをサービスとしてではなく、アプリケーションとして起動することでした。 この場合、エミュレーターは正常に起動し、ボタンを手動で押すことができます（サーバーの再起動後にのみこれを行うだけで十分です-起動すると、エミュレーターは後続のすべてのアセンブリに使用されます）。 それでも、ボタンを自動的にクリックするためのコードを残し、仮想マシンの再起動が「無人」になるようにしました。

エージェントをアプリケーションとして実行することは簡単であることが判明しました-エージェントのbinディレクトリ（デフォルトではc：\ BuildAgent \ bin）には、不要なエージェントサービスを破棄し、アプリケーションとしてエージェントを実行できるbatファイルの良いセットがあります（トピックがあります）

そのため、目的のbatファイルをautorunに書き込み、 システムの起動後に自動ログインを構成し（「メンテナンスフリー」リブート用）、出来上がりです。 ビルドできます！

最後の仕上げは、エミュレーターを起動し、エージェント起動スクリプトでワークステーションをブロックすることでした。 エミュレータは、仮想マシンの再起動後に実行される最初のアセンブリの遅延、および管理者の要求によるロックを除外するために起動する必要がありました（「マシンのコンソールが開いていると意味がありません！」）。

次のステップは、ビルドスクリプトに単体テストを追加することでした。 前述のとおり、テストは、Silverlight Toolkitにバンドルされている単体テストフレームワークの下で実行されました。 エミュレータでの実行はすでに完了したステップであるため、テストは問題なく開始されました。

テスト結果をTeamCityに転送する

さらに、テストは単に実行されるだけでなく、アセンブリが失敗した場合にアセンブリを「クラッシュ」させることは論理的でした。 これを行うには、テストの結果をTeamCityに転送する必要がありました。

もう1つの後退-エミュレーターをアセンブリスクリプトからCoreCon APIを介して制御しました 。 これについては Justin Angelとarty87に感謝します。 つまり、ビルドスクリプトで、実際にエミュレータを制御するコンソールアプリケーションが起動されました。

思いついてすぐにテストされた最初の解決策は、フォールンテストでアセンブリを「ノックダウン」し、ゼロ以外の終了コードでエミュレーター制御アプリケーションを終了することでした。 同時に、コンソールに何かを書くこともできます-TeamCityのビルドログで確認できます。

しかし、TeamCityがテストの統計を保持していることの美しさを望みました。また、アセンブリ中であっても、それらがどのように実行されているかは明確でした（ところで、非常に瞑想的） そのため、 Service Message APIが発掘されましたが、実際にはコンソール出力からの特殊なタイプのタグの「キャッチ」であることが判明しました。 ここに登場した2つの機能：

1. タグは単一行でなければなりません。 TeamCityは、改行をタグの終わりと解釈するため、タグの形式は間違っていて無視されます。 例のドキュメントでは、シーケンス "| n | r"による改行文字の転送が示されていますが、これはうまくいきませんでした。
2. タグは長すぎてはいけません。 スタックトレースから改行を切り取り、それをtestFailedタグの詳細として渡すと、TeamCityはすべての結果を伴う約300文字の結果の長い文字列を任意に分割しました。 興味深いことに、300文字より明らかに長い行の残りの部分は、分割なしでビルドログに表示されました。 私は詳細に実験しなかったので、ビルドログにエラーエラーを表示することにしました
   
   

テストの開始と完了の事実をキャッチし、エミュレータで実行されたコードからエミュレータ制御ユーティリティにすべてを転送するために、2つの問題を解決します（結局、ユーティリティはテストが実行されるエミュレータではなくコンソールに書き込む必要があります）。

最初のタスクは簡単に解決されました。 ユニットテストのフレームワークでは、テスト、テストクラス、およびアセンブリ全体の起動および完了のイベントにサブスクライブすることができ、そのハンドラーで多くの情報（テスト結果、テストが失敗したときの例外、開始および終了時刻など）を見つけることができます。 フレームワークに関するドキュメントを実際に探していませんでした。「pokeメソッド」を使用すると、学習が簡単になりました。

そのため、結果の出力を使用して単体テストを実行するには、標準の開始コードをわずかに変更します。

private void MainPage_Loaded(object sender, RoutedEventArgs e) { var testPage = UnitTestSystem.CreateTestPage(GetSettings()) as IMobileTestPage; BackKeyPress += (x, xe) => xe.Cancel = testPage.NavigateBack(); (Application.Current.RootVisual as PhoneApplicationFrame).Content = testPage; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

変更は、GetSettings関数の呼び出しにあります。 これがまさにこの機能です。

 public static UnitTestSettings GetSettings() { var settings = UnitTestSystem.CreateDefaultSettings(); settings.TestHarness.TestClassStarting += TestHarnessTestClassStarting; settings.TestHarness.TestClassCompleted += TestHarnessTestClassCompleted; settings.TestHarness.TestMethodStarting += TestHarnessTestMethodStarting; settings.TestHarness.TestMethodCompleted += TestHarnessTestMethodCompleted; return settings; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

現在、テストを綿密に監視しています。 イベントハンドラーのコードは簡単なので、引用しません。

ここで、追跡結果をエミュレータ制御プログラムに転送する必要があります。エミュレータ制御プログラムでは、結果をサービスメッセージAPIタグの形式でコンソールに出力できます。

記事で実際に説明されているように、分離ストレージが伝送チャネルとして使用されました。 確かに、提案されたFileDeployerとは異なり、RemoteIsolatedStorageクラスはファイルの交換に使用されました。

しかし、この送信方法はあまり良くありませんでした。 テストに関する情報をリアルタイムで送信したかったため、テスト結果はすぐにエミュレータ上の分離ストレージファイルに書き込まれ、管理ユーティリティはこのファイルを定期的に読み取り、新しく取得した結果をコンソールに表示しました。 ファイルがロックされているため、レコードは定期的に「落ちました」。実行されたテストには影響しませんでしたが、それらに関する情報が失われました。 彼らは「松葉杖」で問題を解決しました-書き込みエラーをキャッチし、エラーで再試行しました。 もちろん、風水では、たとえばIPを介して、より適切な方法でエミュレータとデータを交換する必要があります。 しかし、待ち望まれていた結果がすでに得られているので、私はこれを気にしたくありませんでした：





単体テストでコードカバレッジを制御したいという欲求は満たされていないままでした。 判明したように、SIlverlight Runtimeではコードカバレッジを正常に制御することはできません。 より多くの人は、カバレッジを取得するために、通常の.NET CLRでテストコードを再コンパイルすることをお勧めします。 ただし、Silverlightランタイムに非常に厳密に結び付けられる場合もある利用可能なテストのボリュームでは、これを実行することは実用的ではないと見なされました。 それにもかかわらず、夢は残っていました、そして私は始まった小さなプロジェクトでそれを実現しようとします。 すべてがうまくいき、喜びを分かち合えることを願っています。



PSこれは私の最初の投稿ですので、建設的な批判と提案の準備ができています。