Share via

Xamarin での TeamCity の使用

  • [アーティクル]

"このガイドでは、TeamCity を使ってモバイル アプリケーションをコンパイルし、App Center Test に送信する手順について説明します。"

継続的インテグレーションの概要に関するガイドで説明されているように、継続的インテグレーション (CI) は、高品質のモバイル アプリケーションを開発するときに役立つ方法です。 継続的インテグレーション サーバー ソフトウェアには多くの実行可能なオプションがあります。このガイドでは、JetBrains の TeamCity について説明します。

TeamCity のインストールには、いくつかの異なる組み合わせがあります。 次の一覧では、これらの組み合わせの一部について説明します。

  • Windows サービス - このシナリオでは、Windows が Windows サービスとして起動すると、TeamCity が起動します。 iOS アプリケーションをコンパイルするには、Mac Build Host と組み合わせる必要があります。

  • OS X 上でデーモンを起動する - 概念的には、前の手順で説明した Windows サービスとして実行する場合と似ています。 既定では、ビルドはルート アカウントで実行されます。

  • OS X 上のユーザー アカウント - ユーザーがログインするたびに起動するユーザー アカウントで TeamCity を実行できます。

上記のシナリオでは、OS X 上のユーザー アカウントで TeamCity を実行するのが最も簡単であり、セットアップが最も簡単です。

TeamCity の設定にはいくつかの手順があります。

  • TeamCity のインストール - TeamCity のインストールについては、このガイドでは説明しません。 このガイドは、1 つのユーザー アカウントで TeamCity がインストールされ、実行されていることを前提としています。 TeamCity のインストールに関する手順は、JetBrains の TeamCity 8 のドキュメントを参照してください。

  • ビルド サーバーの準備 - この手順には、モバイル アプリケーションのビルドと配布の準備に必要なソフトウェア、ツール、証明書のインストールが含まれます。

  • ビルド スクリプトの作成 - この手順は厳密には必須ではありませんが、ビルド スクリプトはアプリケーションを自動的にビルドするのに役立ちます。 ビルド スクリプトを使うと、発生する可能性のあるビルドの問題のトラブルシューティングに役立ちます。また、継続的インテグレーションが実践されていない場合でも、一貫した反復可能な方法で配布用のバイナリを作成できます。

  • TeamCity プロジェクトの作成 - 前の 3 つの手順が完了したら、ソース コードの取得、プロジェクトのコンパイル、テストの送信に必要なすべてのメタデータを含む TeamCity プロジェクトを作成し、App Center Test に送信する必要があります。

要件

App Center Test の経験が必要です。

TeamCity 8.1 を使い慣れている必要があります。 TeamCity のインストールについては、このドキュメントの範囲外です。 TeamCity は OS X Mavericks にインストールされており、ルート アカウントではなく通常のユーザー アカウントで実行されていることを前提としています。

ビルド サーバーは、継続的インテグレーション専用であり、OS X を実行するスタンドアロン コンピューターである必要があります。 理想的には、データベース サーバー、Web サーバー、開発者ワークステーションなどの他の役割をビルド サーバーが担わないようにします。

重要

このガイドでは、Xamarin の "ヘッドレス" インストールについては説明しません。

ファイアウォールの構成

テストを Xamarin Test Cloud に送信するため、テストを送信するコンピューターが Test Cloud サーバーと通信できる必要があります。 ファイアウォールは、ポート 80 と 443 の testcloud.xamarin.com にあるサーバーとの間のネットワーク トラフィックを許可するように構成する必要があります。 このエンドポイントは DNS によって管理され、IP アドレスは変更される可能性があります。

場合によっては、テスト (またはテストを実行しているデバイス) が、ファイアウォールによって保護された Web サーバーと通信する必要があります。 このシナリオでは、次の IP アドレスからのトラフィックを許可するようにファイアウォールを構成する必要があります。

  • 195.249.159.238
  • 195.249.159.239

ビルド サーバーの準備

ビルド サーバーを構成する際に重要な手順は、モバイル アプリケーションのビルドに必要なツール、ソフトウェア、証明書をすべてインストールすることです。 ビルド サーバーがモバイル ソリューションをコンパイルし、すべてのテストを実行できることが重要です。 構成の問題を最小限に抑えるには、TeamCity をホストしているのと同じユーザー アカウントにソフトウェアとツールをインストールする必要があります。 必要なものの詳細を次の一覧に示します。

  1. Visual Studio for Mac - これには、Xamarin.iOS と Xamarin.Android が含まれます。
  2. Xamarin コンポーネント ストアにログインする - この手順は省略可能であり、アプリケーションが Xamarin コンポーネント ストアのコンポーネントを使う場合にのみ必要です。 この時点でコンポーネント ストアに事前にログインすると、TeamCity ビルドがアプリケーションをコンパイルしようとするときに問題が発生するのを防ぐことができます。
  3. Xcode - iOS アプリケーションのコンパイルと署名には Xcode が必要です。
  4. Xcode コマンドライン ツール - これについては、rbenv による Ruby の更新に関するガイドのインストールに関するセクションの手順 1 で説明されています。
  5. 署名 ID とプロビジョニング プロファイル - XCode 経由で証明書とプロビジョニング プロファイルをインポートします。 詳細については、署名 ID とプロビジョニング プロファイルのエクスポートに関する Apple のガイドを参照してください。
  6. Android キーストア - 必要な Android キーストアを、TeamCity ユーザーがアクセスできるディレクトリ (つまり ~/Documents/keystores/MyAndroidApp1) にコピーします。
  7. Calabash - Calabash を使って作成されたテストがアプリケーションにある場合、これは省略可能な手順です。 詳細については、OS X Mavericks への Calabash のインストールに関するガイドと rbenv による Ruby の更新に関するガイドを参照してください。

次の図は、これらすべてのコンポーネントを示しています。

This diagram illustrates all of these components

すべてのソフトウェアがインストールされたら、ユーザー アカウントにログインし、すべてのソフトウェアが正しくインストールされ、機能していることを確認します。 これには、ソリューションのコンパイルとアプリケーションの App Center Test への送信が含まれます。 これを簡略化するには、次のセクションで説明するように、ビルド スクリプトを実行します。

ビルド スクリプトを作成する

モバイル アプリケーションのコンパイルと App Center Test への送信のすべての側面を TeamCity 単独で処理できますが、ビルド スクリプトを作成することをお勧めします。 ビルド スクリプトには次の利点があります。

  1. ドキュメント - ビルド スクリプトは、ソフトウェアのビルド方法に関するドキュメントの 1 つの形式として機能します。 これにより、アプリケーションの展開に伴う "魔法" の一部がなくなり、開発者は機能に集中できるようになります。
  2. 反復可能性 - ビルド スクリプトを使うと、アプリケーションがコンパイルおよび展開されるたびに、誰が作業を行うかに関係なく、同じ方法で行われることを確保できます。 この反復可能な一貫性があるので、誤って実行されたビルドや人為的エラーが原因で発生する可能性のある問題やエラーをなくすことができます。
  3. バージョン管理 - ビルド スクリプトをソース管理システムに含めることができます。 これは、ビルド スクリプトへの変更を追跡、監視し、エラーや不正確な点が見つかった場合に修正できることを意味します。
  4. 環境を準備する - ビルド スクリプトには、必要なサード パーティの依存関係をインストールするロジックを含めることができます。 これにより、確実に適切なコンポーネントを使ってアプリケーションをビルドできます。

ビルド スクリプトは、PowerShell ファイル (Windows の場合) または bash スクリプト (OS X の場合) と同じくらい簡単です。 ビルド スクリプトを作成する場合、スクリプト言語にはいくつかの選択肢があります。

  • Rake - これは、Ruby に基づいた、プロジェクトをビルドするためのドメイン固有言語 (DSL) です。 Rake には人気があり、ライブラリのエコシステムが豊富であるという利点があります。

  • psake - これはソフトウェアをビルドするための Windows PowerShell ライブラリです

  • FAKE - これは、必要に応じて既存の .NET ライブラリを使用できる F# ベースの DSL です。

どのスクリプト言語を使うかは、好みと要件によって異なります。

Note

MSBuild や NAnt などの XML ベースのビルド システムを使うこともできますが、これらにはソフトウェアのビルド専用である DSL の表現力と保守性がありません。

ビルド スクリプトのパラメーター化

ソフトウェアのビルドとテストのプロセスでは、秘密にしておく必要がある情報が必要です。 APK を作成するには、キーストアのパスワードやキーストア内のキー エイリアスが必要になる場合があります。 同様に、App Center Test には、開発者に固有の API キーが必要です。 このような種類の値は、ビルド スクリプトにハードコーディングしないでください。 そうではなく、変数としてビルド スクリプトに渡すようにしてください。

App Center がテストの実行に使う必要があるデバイスを特定する iOS デバイス ID や Android デバイス ID などの値は、それほど機密性が高くありません。 これらは保護する必要がある値ではありませんが、ビルドごとに変わる可能性があります。

このような種類の変数をビルド スクリプトの外部に保存すると、組織内で (開発者などと) ビルド スクリプトを簡単に共有できます。 開発者はビルド サーバーとまったく同じスクリプトを使用できますが、自分自身のキーストアと API キーを使用できます。

このような機密性の高い値を保存するには、次の 2 つのオプションが考えられます。

  • 構成ファイル - API キーを保護するために、この値はバージョン コントロールにチェックインしないでください。 ファイルはマシンごとに作成できます。 このファイルから値を読み取る方法は、使うスクリプト言語によって異なります。

  • 環境変数 - これらはマシンごとに簡単に設定できます。また、基となるスクリプト言語に依存しません。

これらの選択肢にはそれぞれ長所と短所があります。 TeamCity は環境変数と適切に連携するため、このガイドではビルド スクリプトを作成するときにこの手法を推奨します。

ビルド ステップ

ビルド スクリプトでは、次の手順を実行する必要があります。

  • アプリケーションをコンパイルする - これには、適切なプロビジョニング プロファイルを使ってアプリケーションを署名することが含まれます。

  • アプリケーションを Xamarin Test Cloud に送信する - これには、APK を適切なキーストアに合わせて署名し、zipalign 処理をすることが含まれます。

これら 2 つの手順については、後でさらに詳しく説明します。

Xamarin.iOS アプリケーションのコンパイル

次のコマンド ラインでは、iPhone 用のソリューション SOLUTION_FILE.sln のリリース ビルドを指定しています。 IPA の場所は、コマンド ラインで IpaPackageDir プロパティを指定することで設定できます。

  • Mac 上では xbuild を使います。

    xbuild /p:Configuration="Release" \ 
       /p:Platform="iPhone" \ 
       /p:IpaPackageDir="$HOME/Builds" \
       /t:Build MyProject.sln

通常、xbuild コマンドはディレクトリ /Library/Frameworks/Mono.framework/Commands にあります。

  • Windows 上では msbuild を使います。

    msbuild /p:Configuration="Release" 
        /p:Platform="iPhone" 
        /p:IpaPackageDir="%USERPROFILE%\Builds" 
        /p:ServerAddress="192.168.1.3" /p:ServerUser="macuser"  
        /t:Build MyProject.sln

msbuild は、コマンド ラインで渡された $( ) 式を自動的に展開しません。 このため、コマンド ラインで IpaPackageDir を設定するときは、完全なパスを使うことをお勧めします。

IpaPackageDir プロパティの詳細については、iOS 9.8 のリリース ノートを参照してください。

Xamarin.Android アプリケーションのコンパイル

Android アプリケーションをコンパイルするには、xbuild (Windows 上では msbuild) を使います。

/Library/Frameworks/Mono.framework/Commands/xbuild /t:SignAndroidPackage /p:Configuration=Release /path/to/android.csproj

Android アプリケーション xbuild のコンパイルにはプロジェクトが使われ、iOS アプリケーション xbuild にはソリューションが使われます。

Xamarin.UITest を App Center に送信する

次のスニペットに示すように、UITest は App Center CLI を使って送信されます。

appcenter test run uitest --app <TEAM-NAME/APP-NAME> --devices <DEVICE_SET> --token <API_KEY> --app-path <appname.APK-or-appname.IPA> --merge-nunit-xml report.xml --build-dir pathToUITestBuildDir

テストを実行すると、テスト結果は report.xml という NUnit スタイルの XML ファイルの形式で返されます。 この情報は TeamCity のビルド ログに表示されます。

UITest を App Center に送信する方法の詳細については、「Xamarin.Android アプリの準備」または「Xamarin.iOS アプリの準備」を参照してください。

App Center への Calabash テストの送信

次のスニペットに示すように、Calabash テストは App Center CLI を使って送信されます。

appcenter test run calabash --app <TEAM-NAME/APP-NAME> --devices <DEVICE_SET> --token <API_KEY> --app-path <appname.APK-or-appname.IPA> --project-dir pathToProjectDir

Android アプリケーションを App Center Test に送信するには、まず calabash-android を使って APK テスト サーバーをリビルドする必要があります。

$ calabash-android build </path/to/signed/APK>
$ appcenter test run calabash --app <TEAM-NAME/APP-NAME> --devices <DEVICE_SET> --token <API_KEY> --app-path <appname.APK> --project-dir pathToProjectDir

Calabash テストの送信の詳細については、Test Cloud への Calabash テストの送信に関する Xamarin のガイドを参照してください。

TeamCity プロジェクトの作成

TeamCity をインストールし、Visual Studio for Mac でプロジェクトをビルドできるようになったら、次は TeamCity でプロジェクトを作成してプロジェクトをビルドし、App Center に送信してみましょう。

  1. まず、Web ブラウザーを使って TeamCity にログインします。 ルート プロジェクトに移動します。

    Navigate to the Root Project ルート プロジェクトの下に、新しいサブプロジェクトを作成します。

    Navigate to the Root Project Underneath the Root Project, create a new subproject

  2. サブプロジェクトを作成したら、新しいビルド構成を追加します。

    Once the subproject is created, add a new Build Configuration

  3. VCS プロジェクトをビルド構成にアタッチします。 これは、[バージョン コントロールの設定] 画面で行います。

    This is done via the Version Control Setting screen

    VCS プロジェクトが作成されていない場合は、以下に示す [新しい VCS ルート] ページからプロジェクトを作成できます。

    If there's no VCS project created, you can create one from the New VCS Root page

    VCS ルートがアタッチされると、TeamCity によってプロジェクトがチェックアウトされ、ビルド ステップの自動検出が試行されます。 TeamCity を使い慣れている場合は、検出されたビルド ステップのいずれかを選択できます。 この時点では、検出されたビルド ステップを無視しても問題ありません。

  4. 次に、ビルド トリガーを構成します。 これにより、ユーザーがコードをリポジトリにコミットしたときなど、特定の条件が満たされたときにビルドがキューに登録されます。 次のスクリーンショットは、ビルド トリガーを追加する方法を示しています。

    This screenshot shows how to add a build trigger ビルド トリガーの構成例を次のスクリーンショットに示します。

    An example of configuring a build trigger can be seen in this screenshot

  5. 前のセクション「ビルド スクリプトのパラメーター化」では、いくつかの値を環境変数として保存することをお勧めしました。 これらの変数は、[パラメーター] 画面からビルド構成に追加できます。 次のスクリーンショットに示すように、App Center API キー、iOS デバイス ID、Android デバイス ID の変数を追加します。

    Add the variables for the App Center Test API Key, the iOS device ID, and the Android Device ID

  6. 最後の手順は、ビルド スクリプトを呼び出してアプリケーションをコンパイルし、アプリケーションを App Center Test のキューに登録するビルド ステップを追加することです。 次のスクリーンショットは、Rakefile を使ってアプリケーションをビルドするビルド ステップの例です。

    This screenshot is an example of a build step that uses a Rakefile to build an application

  7. この時点で、ビルド構成は完了です。 ビルドをトリガーして、プロジェクトが適切に構成されていることを確認することをお勧めします。 これを行うには、小さくて重要ではない変更をリポジトリにコミットすることをお勧めします。 TeamCity によってコミットが検出され、ビルドが開始されます。

  8. ビルドが完了したら、ビルド ログを調べて、注意が必要な問題や警告がビルドにあるかどうかを確認します。

まとめ

このガイドでは、TeamCity を使って Xamarin モバイル アプリケーションをビルドし、それを App Center Test に送信する方法について説明しました。 ビルド プロセスを自動化するビルド スクリプトの作成について説明しました。 ビルド スクリプトは、アプリケーションのコンパイル、App Center Test への送信、結果の待機を行います。

次に、開発者がコードをコミットするたびにビルドをキューに登録し、ビルド スクリプトを呼び出すプロジェクトを TeamCity で作成する方法について説明しました。