Xamarin での TeamCity の使用Using Team City with Xamarin

このガイドでは、TeamCity を使用してモバイルアプリケーションをコンパイルし、Xamarin Test Cloud に送信するために必要な手順について説明します。This guide will discuss the steps involved with using TeamCity to compile mobile applications and then submit them to Xamarin Test Cloud.

継続的インテグレーションの概要」で説明したように、継続的インテグレーション (CI) は、品質の高いモバイルアプリケーションを開発するときに便利な方法です。As discussed in the Introduction to Continuous Integration guide, continuous integration (CI) is a useful practice when developing quality mobile applications. 継続的インテグレーションサーバーソフトウェアには、さまざまなオプションが用意されています。このガイドでは、JetBrains からのTeamcityに注目します。There are many viable options for continuous integration server software; this guide will focus on TeamCity from JetBrains.

TeamCity のインストールには、いくつかの異なる順列があります。There are several different permutations of a TeamCity installation. これらのいくつかの一覧を次に示します。The following is a list of some of these:

  • Windows サービス–このシナリオでは、Windows が windows サービスとして起動すると teamcity が開始されます。Windows Service – In this scenario, TeamCity starts up when Windows boots as a Windows Service. IOS アプリケーションをコンパイルするには、Mac ビルドホストとペアリングする必要があります。It must be paired with a Mac Build Host to compile any iOS applications.

  • OS X でデーモンを起動する–概念的には、これは前の手順で説明した Windows サービスとして実行するのとよく似ています。Launch Daemon on OS X – Conceptually, this is very similar to running as a Windows Service described in the previous step. 既定では、ビルドはルートアカウントで実行されます。By default the builds will be run under the root account.

  • OS X のユーザーアカウント–ユーザーがログインするたびに起動するユーザーアカウントで teamcity を実行できます。User Account on OS X – It is possible to run TeamCity under a user account that starts up each time the user logs in.

前のシナリオでは、OS X のユーザーアカウントで TeamCity を実行するのが最も簡単で、簡単にセットアップできます。Of the previous scenarios, running TeamCity under a user account on OS X is the simplest and easiest to setup.

TeamCity の設定には、次のようないくつかの手順が含まれます。There are several steps involved with setting up TeamCity:

  • Teamcity のインストール– teamcity のインストールについては、このガイドでは説明しません。Installing TeamCity – The installation of TeamCity is not covered in this guide. このガイドでは、TeamCity がインストールされ、ユーザーアカウントで実行されていることを前提としています。This guide assumes that TeamCity is installed and running under a user account. TeamCity のインストール手順については、JetBrains によるteamcity 8 のドキュメントを参照してください。Instructions on installing TeamCity can be found in the TeamCity 8 documentation by JetBrains.

  • ビルドサーバーの準備: この手順では、モバイルアプリケーションを構築し、配布の準備を行うために必要なソフトウェア、ツール、および証明書をインストールします。Preparing the Build Server – This step involves installing the necessary software, tools, and certificates required to build mobile applications and prepare them for distribution.

  • ビルドスクリプトの作成-この手順は、厳密には必要ありませんが、ビルドスクリプトは、アプリケーションを無人でビルドするのに役立ちます。Creating A Build Script – This step is not strictly necessary, but a build script is a useful aid to building applications unattended. ビルドスクリプトを使用すると、発生する可能性のあるビルドの問題のトラブルシューティングに役立ち、継続的インテグレーションが実行されていない場合でも、一貫性のある反復可能な方法で配布用のバイナリを作成できます。Using a build script will help with troubleshooting build issues that may arise and provides a consistent, repeatable way to create the binaries for distribution, even if continuous integration is not practiced.

  • TeamCity プロジェクトの作成–前の3つの手順が完了したら、ソースコードを取得し、プロジェクトをコンパイルして、テストを Xamarin Test Cloud に送信するために必要なすべてのメタデータを含む teamcity プロジェクトを作成する必要があります。Creating A TeamCity Project – Once the previous three steps are completed, we must create a TeamCity project that will contain all of the meta-data necessary to retrieve the source code, compile the projects, and submit the tests to Xamarin Test Cloud.

要件Requirements

App Center テストの経験が必要です。Experience with App Center Test is required.

TeamCity 8.1 に関する知識が必要です。Familiarity with TeamCity 8.1 is required. TeamCity のインストールについては、このドキュメントでは説明しません。The installation of TeamCity is beyond the scope of this document. TeamCity は OS X Mavericks にインストールされており、ルートアカウントではなく通常のユーザーアカウントで実行されていることを前提としています。It is assumed that TeamCity is installed on OS X Mavericks and is running under a regular user account and not the root account.

ビルドサーバーは、継続的インテグレーション専用の、OS X を実行するスタンドアロンコンピューターである必要があります。The build server should be a stand-alone computer, running OS X, that is dedicated to continuous integration. 理想的には、ビルドサーバーは、データベースサーバー、web サーバー、開発者ワークステーションなどの他のロールに対して責任を負いません。Ideally, the build server will not be responsible for any other roles, such as a database server, web server, or developer workstation.

重要

このガイドでは、Xamarin の "ヘッドレス" インストールについては説明しません。This guide does not cover a "headless" installation of Xamarin.

ファイアウォールの構成Firewall Configuration

テストを Xamarin Test Cloud に送信するためには、テストを送信するコンピューターが、Test Cloud サーバーと通信できる必要があります。In order for tests to be submitted to Xamarin Test Cloud, the computer submitting the tests must be able to communicate with the Test Cloud servers. ファイアウォールを、ポート 80 と 443 の testcloud.xamarin.com のサーバーの往復のネットワークトラフィックを許可するように構成する必要があります。Firewalls must be configured to allow network traffic to and from the servers located at testcloud.xamarin.com on ports 80 and 443. このエンドポイントは DNS によって管理され、IP アドレスは変更されることがあります。This endpoint is managed by DNS and the IP address is subject to change.

場合によっては、テスト (または、テストを実行しているデバイス) がファイアウォールで保護された web サーバーと通信する必要があります。In some situations, a test (or a device running the test) must communicate with web servers protected by a firewall. その場合は、ファイアウォールを、次の IP アドレスからのトラフィックを許可するように構成する必要があります。In this scenario the firewall must be configured to allow traffic from the following IP addresses:

  • 195.249.159.238195.249.159.238
  • 195.249.159.239195.249.159.239

ビルドサーバーの準備Preparing the Build Server

ビルドサーバーを構成するための重要な手順は、モバイルアプリケーションをビルドするために必要なすべてのツール、ソフトウェア、および証明書をインストールすることです。A crucial step in configuring a build server is to install all of the necessary tools, software, and certificates to build the mobile applications. ビルドサーバーでモバイルソリューションをコンパイルし、テストを実行できることが重要です。It is important that the build server be able to compile the mobile solution and run any tests. 構成の問題を最小限に抑えるには、TeamCity をホストしているのと同じユーザーアカウントにソフトウェアとツールをインストールする必要があります。To minimize configuration issues, the software and tools should be installed in the same user account that is hosting TeamCity. 必要なものの一覧を次に示します。The following is a list of what is required:

  1. Visual Studio for Mac –これには、Xamarin と xamarin Android が含まれます。Visual Studio for Mac – This includes Xamarin.iOS and Xamarin.Android.
  2. Xamarin コンポーネントストアにログインする–これはオプションの手順であり、アプリケーションが Xamarin コンポーネントストアのコンポーネントを使用する場合にのみ必要です。Login to the Xamarin Component Store – This is an optional step and is only required if your application uses Components from the Xamarin Component store. この時点でコンポーネントストアに事前にログインすると、TeamCity ビルドがアプリケーションのコンパイルを試行しても問題が発生しなくなります。Proactively logging into the Component store at this point will prevent any issues when a TeamCity build tries to compile the application.
  3. Xcode – Xcode は、iOS アプリケーションをコンパイルして署名するために必要です。Xcode – Xcode is required to compile and sign iOS applications.
  4. Xcode コマンドラインツール–「 Ruby With rbenv の更新」ガイドの「インストール」セクションの手順 1. で説明されています。Xcode Command Line Tools – This is described in step 1 of the Installation section of the Updating Ruby with rbenv guide.
  5. & プロビジョニングプロファイルの署名 id : XCode を使用して証明書とプロビジョニングプロファイルをインポートします。Signing Identity & Provisioning Profiles – Import the certificates and provisioning profile via XCode. 詳細については、「署名 id とプロビジョニングプロファイルのエクスポートに関する Apple のガイド」を参照してください。Please see Apple’s guide on Exporting Signing Identities and Provisioning Profiles for more details.
  6. Android キーストア–必要な android キーストアを teamcity ユーザーがアクセスできるディレクトリにコピーします。つまり、~/Documents/keystores/MyAndroidApp1 です。Android Keystores – Copy the required Android keystores to a directory that the TeamCity user has access to, i.e. ~/Documents/keystores/MyAndroidApp1.
  7. Calabash –アプリケーションに calabash を使用して記述されたテストがある場合は、これは省略可能な手順です。Calabash – This is an optional step if your application has tests written using Calabash. 詳細については、「 OS X Mavericks に Calabash をインストールする」および「 Ruby With rbenv を更新する」ガイドを参照してください。Please see the Installing Calabash on OS X Mavericks guide and the Updating Ruby with rbenv guide for more information.

次の図は、これらすべてのコンポーネントを示しています。The following diagram illustrates all of these components:

すべてのソフトウェアがインストールされたら、ユーザーアカウントにログインし、すべてのソフトウェアが正しくインストールされ、動作していることを確認します。Once all of the software has been installed, log in to the user account and confirm that all of the software has been properly installed and is working. これには、ソリューションをコンパイルし、Test Cloud にアプリケーションを送信する必要があります。This should involve compiling the solution and submitting the application to Test Cloud. これは、次のセクションで説明するように、ビルドスクリプトを実行することで大幅に簡素化できます。This can be greatly simplified by running the build script, as described in the next section.

ビルドスクリプトの作成Create a Build Script

TeamCity では、コンパイルとモバイルアプリケーションの送信のすべての側面を処理して Test Cloud することができますが、ビルドスクリプトを作成することを強くお勧めします。Although it is entirely possible for TeamCity to handle all aspects of compiling and submitting the mobile applications to Test Cloud by itself, it is strongly recommended to create a build script. ビルドスクリプトには、次のような利点があります。A build script provides the following advantages:

  1. ドキュメント–ビルドスクリプトは、ソフトウェアの構築方法に関するドキュメントの形式として機能します。Documentation – A build script serves as a form of documentation on how the software is built. これにより、アプリケーションの配置に関連する "マジック" の一部が削除され、開発者は機能に専念できます。This removes some of the “magic” that is associated with deploying the application and allows developers to concentrate on functionality.
  2. 再現性: ビルドスクリプトを使用すると、アプリケーションをコンパイルして配置するたびに、どのユーザーがどのように動作するかに関係なく、まったく同じ方法で動作します。Repeatability – A build script ensures that each time the application is compiled and deployed, it happens in exactly the same way, regardless of who or what does the work. この反復可能な一貫性によって、ビルドまたは人的エラーが不適切に実行されたことが原因で、でクリープする可能性のある問題またはエラーが除去されます。This repeatable consistency removes any issues or errors that might creep in due to an incorrectly executed build or human error.
  3. バージョン管理-ビルドスクリプトをソース管理システムに含めることができます。Versioning – A build script can be included in the source control system. つまり、ビルドスクリプトへの変更を追跡、監視、修正して、エラーまたは誤りが見つかった場合には修正できます。This means that changes to the build script can be tracked, monitored, and corrected if errors or inaccuracies are found.
  4. 環境を準備する–ビルドスクリプトには、必要なサードパーティの依存関係をインストールするロジックを含めることができます。Prepare the Environment – A build script can include logic to install any required 3rd party dependencies. これにより、アプリケーションが適切なコンポーネントでビルドされるようになります。This will ensure that the applications are built with the proper components.

ビルドスクリプトは、Powershell ファイル (Windows の場合) または bash スクリプト (OS X の場合) のように簡単にできます。The build script can be as simple as a Powershell file (on Windows) or a bash script (on OS X). ビルドスクリプトを作成する場合、スクリプト言語にはいくつかの選択肢があります。When creating the build script, there are several choices for scripting languages:

  • rake – Ruby に基づいてプロジェクトを構築するためのドメイン固有言語 (DSL) になります。Rake – this is a Domain Specific Language (DSL) for building projects, based on Ruby. rake は、人気の利点とライブラリの豊富なエコシステムがあります。Rake has the advantage of popularity and a rich ecosystem of libraries.

  • psake - ソフトウェアを構築するための Windows Powershell ライブラリですpsake – this is a Windows Powershell library for building software

  • FAKE – これは、ベースの DSLF#に必要な場合は、既存の .NET ライブラリを利用できるようにします。FAKE – this is a DSL based in F# which makes it possible to utilize existing .NET libraries if necessary.

どのスクリプト言語が使用されるかは、ユーザーの好みや要件によって異なります。Which scripting language is used depends on your preferences and requirements. TaskyPro Calabash例にはとして、rake を使用する例が含まれています、ビルド スクリプトします。The TaskyPro-Calabash example contains an example of using Rake as a build script.

注意

MSBuild や NAnt などの XML ベースのビルドシステムを使用することもできますが、本ソフトウェアの構築専用の DSL の表現力や保守性は欠けています。It is possible to use an XML based build system such as MSBuild or NAnt, but these lack the expressiveness and maintainability of a DSL that is dedicated to building software.

ビルドスクリプトのパラメーター化Parameterizing The Build Script

ソフトウェアのビルドとテストのプロセスには、機密情報を保持する必要がある情報が必要です。The process of building and testing software requires information that should be kept secret. 特に、APK の作成には、キーストアのパスワード、またはキーストアのキーエイリアスが必要になる場合があります。In particular creating an APK may require a password for the keystore and/or the key alias in the keystore. 同様に、Test Cloud には、開発者に固有の API キーが必要です。Likewise, Test Cloud requires an API key that is unique to a developer. これらの種類の値は、ビルドスクリプトでハードコーディングしないでください。These types of values should not be hard coded in the build script. 代わりに、変数としてビルドスクリプトに渡す必要があります。Instead they should be passed as variables to the build script.

機密性が低いは、iOS デバイス ID や、テストの実行に使用 Test Cloud デバイスを識別する Android デバイス ID などの値です。Less sensitive are values such as the iOS device ID or the Android device ID that identify what devices Test Cloud should use for test runs. これらは、保護する必要がある値ではなく、ビルドごとに変更される可能性があります。These are not values that need to be protected, but they may change from build to build.

これらの種類の変数をビルドスクリプトの外部に格納すると、開発者は、たとえば、組織内でビルドスクリプトを共有しやすくなります。Storing these types of variables outside of the build script also makes it easier to share the build script within an organization, with developers for example. 開発者は、ビルドサーバーとまったく同じスクリプトを使用できますが、独自のキーストアと API キーを使用できます。Developers may use the exact same script as the build server, but can use their own keystores and API keys.

これらの機密値を格納するには、次の2つのオプションを使用できます。There are two possible options for storing these sensitive values:

  • 構成ファイル– Test Cloud API キーを保護するには、この値をバージョン管理にチェックインしないようにする必要があります。A configuration file – To protect the Test Cloud API key this value should not be checked into version control. ファイルは、コンピューターごとに作成できます。The file can be created for each machine. このファイルから値を読み取る方法は、使用するスクリプト言語によって異なります。How values are read from this file depends on the scripting language used.

  • 環境変数–コンピューター単位で簡単に設定でき、基になるスクリプト言語に依存しません。Environment variables – these can be easily set on a per-machine basis and ared independent of the underlying scripting language.

これらの選択肢には長所と短所があります。There are advantages and disadvantages to each of these choices. TeamCity は環境変数で適切に動作するため、このガイドではビルドスクリプトを作成するときにこの手法をお勧めします。TeamCity works nicely with environment variables, so this guide will recommend this technique when creating build scripts.

ビルドステップBuild Steps

ビルドスクリプトは、次の手順を実行できる必要があります。The build script must be able to perform the following steps:

  • アプリケーションをコンパイルします。これには、適切なプロビジョニングプロファイルを使用したアプリケーションへの署名も含まれます。Compile the Application – This includes signing the application with the correct provisioning profile.

  • アプリケーションを Xamarin Test Cloud に送信します。これには、適切なキーストアを使用して apk を署名し、zip に揃えることが含まれます。Submit the Application to Xamarin Test Cloud – This includes signing and zip aligning the APK with the appropriate keystore.

これらの2つの手順については、以下で詳しく説明します。These two steps will be explained in more detail below.

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

以下のコマンドラインは、iPhone 用の SOLUTION_FILE.sln というソリューションのリリースビルドを指定するものです。The following command line to specify a Release build of the solution SOLUTION_FILE.sln for the iPhone. IPA の場所を設定するには、コマンドラインIpaPackageDirでプロパティを指定します。The location of the IPA can be set by specifying the IpaPackageDir property on the command line:

  • Mac における xbuild の使用:On the Mac, using xbuild:

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

Xbuild コマンドは、通常 /Library/Frameworks/Mono.framework/Commands ディレクトリにあります。The xbuild command is typically found in the directory /Library/Frameworks/Mono.framework/Commands.

  • Windows における msbuild の使用:On Windows, using 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 は、コマンドラインによって渡される $( ) 式を、自動的に展開しません。msbuild will not automatically expand $( ) expressions passed in by the command line. このため、コマンドラインで IpaPackageDir を設定する場合は、フルパスを使うことをお勧めします。For this reason it is recommended to use a full path when setting the IpaPackageDir at the command line.

IpaPackageDir プロパティについてのより詳しい情報は、iOS 9.8 のリリースノート を参照してください。See the Release Notes for iOS 9.8 for more details about the IpaPackageDir property.

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

Android アプリケーションをコンパイルするには、 xbuild (または Windows 上のmsbuild ) を使用します。To compile an Android application, use xbuild (or msbuild on Windows):

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

Xamarin Android アプリケーションをコンパイルすると、 xbuildによってプロジェクトが使用され、iOS アプリケーションをビルドするにはソリューションが必要になりますNotice that to compile the Xamarin Android application xbuild uses the project, and that to build the iOS application xbuild requires the solution.

UITests を Test Cloud に送信していますSubmitting Xamarin.UITests to Test Cloud

UITests は、次のスニペットに示すように @no__t 0 アプリケーションを使用して送信されます。UITests are submitted using the test-cloud.exe application, as shown in the following snippet:

test-cloud.exe <path-to-apk-or-ipa-file> <test-cloud-team-api-key> --devices <device-selection-id> --assembly-dir <path-to-tests-containing-test-assemblies> --nunit-xml report.xml --user <email>

テストが実行されると、テスト結果は、レポート xmlという NUnit 形式の xml ファイルの形式で返されます。When the test is run, the test results will be returned in the form of an NUnit style XML file called report.xml. TeamCity によって、ビルドログに情報が表示されます。TeamCity will display the information in the Build Log.

UITests を Test Cloud に送信する方法の詳細については、「 Xamarin Android アプリの準備」または「 Xamarin の IOS アプリの準備」を参照してください。For more information about how to submit UITests to Test Cloud, consult Preparing Xamarin.Android Apps or Preparing Xamarin.iOS Apps.

Test Cloud に対する Calabash テストの送信Submitting Calabash Tests to Test Cloud

Calabash テストは、次のスニペットに示すように @no__t 0 の gem を使用して送信されます。Calabash tests are submitted using the test-cloud gem, as shown in the following snippet:

test-cloud submit /path/to/APK-or-IPA <test-cloud-team-api-key> --devices <device-id> --user <email>

Android アプリケーションを Test Cloud に送信するには、最初に calabash-android を使用して APK テストサーバーを再構築する必要があります。To submit an Android application to Test Cloud, it is necessary to first rebuild the APK test server using calabash-android:

$ calabash-android build </path/to/signed/APK>
$ test-cloud submit /path/to/APK <test-cloud-team-api-key> --devices <ANDROID_DEVICE_ID> --profile=android --config=config/cucumber.yml --pretty

Calabash テストの送信の詳細については、 Test Cloud への Calabash テストの送信に関する Xamarin のガイドを参照してください。For more information on submitting Calabash tests, please consult Xamarin’s guide on Submitting Calabash Tests to Test Cloud.

TeamCity プロジェクトの作成Creating a TeamCity Project

TeamCity がインストールされ Visual Studio for Mac、プロジェクトをビルドできるようになったら、TeamCity でプロジェクトを作成してプロジェクトをビルドし、Test Cloud に送信します。Once TeamCity is installed and Visual Studio for Mac can build your project, it is time to create a project in TeamCity to build the project and submit it to Test Cloud.

  1. Web ブラウザーを使用して TeamCity にログインすることで開始されます。Started by logging into TeamCity via the web browser. ルートプロジェクトに移動します。Navigate to the Root Project:

    ルート![プロジェクトに移動]し、ルートプロジェクトの下(teamcity-images/image2.png "にあるルートプロジェクトに移動")して、新しいサブプロジェクトを作成します。Navigate to the Root Project Underneath the Root Project, create a new sub-project:

    ルートプロジェクト![の下にあるルートプロジェクトに移動し、新しいサブプロジェクトを作成]します。ルートプロジェクトの下にあるルートプロジェクト(teamcity-images/image3.png "に移動し、新しいサブプロジェクトを作成")します。Navigate to the Root Project Underneath the Root Project, create a new sub-project

  2. サブプロジェクトが作成されたら、新しいビルド構成を追加します。Once the sub-project has been created, add a new Build Configuration:

    サブプロジェクトが作成されたら、れた後に新しいビルド構成を追加し、新しいビルド構成を追加します。Once the sub-project has been created, add a new Build Configuration

  3. ビルド構成に VCS プロジェクトをアタッチします。Attach a VCS project to the Build Configuration. これを行うには、[バージョンコントロールの設定] 画面を使用します。This is done via the Version Control Setting screen:

    ![これを行うには]、バージョンコントロールの設定画面を使用(teamcity-images/image6.png "します。これは、[バージョンコントロールの設定] 画面で行います")。This is done via the Version Control Setting screen

    VCS プロジェクトが作成されていない場合は、次に示す新しい VCS ルートページから作成することもできます。If there is no VCS project created, you have the option to create one from the New VCS Root page shown below:

    ![Vcs プロジェクトが作成]されていない場合は、新しい vcs ルートページから作成することもできます。(teamcity-images/image7.png "vcs プロジェクトが作成")されていない場合は、新しい vcs ルートページから作成することもできます。If there is no VCS project created, you have the option to create one from the New VCS Root page

    VCS のルートがアタッチされると、TeamCity によってプロジェクトがチェックアウトされ、ビルドのステップが自動的に検出されます。Once the VCS root has been attached, TeamCity will checkout the project and try to auto detect build steps. TeamCity を使い慣れている場合は、検出されたビルドステップのいずれかを選択できます。If you are familiar with TeamCity, then you can select one of the detected build steps. 現時点では、検出されたビルドの手順を無視しても安全です。It is safe to ignore the detected build steps for now.

  4. 次に、ビルドトリガーを構成します。Next, configure a Build Trigger. これにより、ユーザーがリポジトリにコードをコミットしたときなど、特定の条件が満たされたときにビルドがキューに入れられます。This will queue up a build when certain conditions are met, such as when a user commits code to the repository. 次のスクリーンショットは、ビルドトリガーを追加する方法を示しています。The following screenshot shows how to add a build trigger:

    ![このスクリーンショット]は、ビルドトリガーを追加する方法を示しています。このスクリーンショットでは、ビルドトリガーを(teamcity-images/image8.png "追加する方法を示し")ています。次のスクリーンショットを参照してください。This screenshot shows how to add a build trigger An example of configuring a build trigger can be seen in the following screenshot:

    ![ビルドトリガーを構成する例]については、このスクリーンショットをご覧ください。(teamcity-images/image9.png "ビルドトリガーを構成する例については、このスクリーンショット")をご覧ください。An example of configuring a build trigger can be seen in this screenshot

  5. 前のセクション「ビルドスクリプトのパラメーター化」では、環境変数としていくつかの値を格納することを推奨していました。The previous section, Parameterizing the Build Script, suggested storing some values as environment variables. これらの変数は、[パラメーター] 画面を使用してビルド構成に追加できます。These variables can be added to the build configuration via the Parameters screen. 次のスクリーンショットに示すように、Test Cloud API キー、iOS デバイス ID、および Android デバイス ID の変数を追加します。Add the variables for the Test Cloud API Key, the iOS device ID, and the Android Device ID as shown in the screenshot below:

    ![TEST CLOUD Api キー、ios デバイス id、および Android デバイス id の変数を追加]して、(teamcity-images/image11.png "Test Cloud API キー、ios デバイス Id、および android デバイス id の変数を追加")します。Add the variables for the Test Cloud API Key, the iOS device ID, and the Android Device ID

  6. 最後の手順では、ビルドスクリプトを呼び出してアプリケーションをコンパイルし、アプリケーションを Test Cloud にエンキューするビルドステップを追加します。The final step is to add a build step that will invoke the build script to compile the application and enqueue the application to Test Cloud. 次のスクリーンショットは、Rakefile を使用してアプリケーションをビルドするビルドステップの例です。The following screenshot is an example of a build step that uses a Rakefile to build an application:

    ![このスクリーンショットは、Rakefile を使用してアプリケーションをビルドするビルドステップの例]です。(teamcity-images/image12.png "このスクリーンショットは、rakefile を使用してアプリケーションをビルドするビルドステップの例です")。This screenshot is an example of a build step that uses a Rakefile to build an application

  7. この時点で、ビルド構成が完了します。At this point, the build configuration is complete. ビルドをトリガーして、プロジェクトが適切に構成されていることを確認することをお勧めします。It is a good idea to trigger a build to confirm that the project is properly configured. これを行うには、小規模で重要ではない変更をリポジトリにコミットすることをお勧めします。A good way to do this is to commit a small, insignificant change to the repository. TeamCity はコミットを検出し、ビルドを開始する必要があります。TeamCity should detect the commit and start a build.

  8. ビルドが完了したら、ビルドログを調べ、注意が必要なビルドに問題または警告があるかどうかを確認します。Once the build has completed, inspect the build log and see if there are any problems or warnings with the build that require attention.

まとめSummary

このガイドでは、TeamCity を使用して Xamarin モバイルアプリケーションをビルドし、Test Cloud に送信する方法について説明します。This guide covered how to use TeamCity to build Xamarin Mobile applications and then submit them to Test Cloud. ビルドプロセスを自動化するためのビルドスクリプトの作成について説明しました。We discussed creating a build script to automate the build process. ビルドスクリプトは、アプリケーションのコンパイル、Test Cloud への送信、および結果の待機を行います。The build script takes care of compiling the application, submitting to Test Cloud, and waiting for the results

次に、開発者がコードをコミットしてビルドスクリプトを呼び出すたびにビルドをキューにする、TeamCity でプロジェクトを作成する方法について説明します。Then we covered how to create a project in TeamCity that will queue a build each time a developer commits code and will call the build script.