Xamarin との継続的インテグレーションの概要Introduction to Continuous Integration with Xamarin

継続的インテグレーションは、プロジェクトのバージョン管理リポジトリ内の開発者によってコードが追加または変更されたときに、自動ビルドによってコンパイルされ、必要に応じてアプリをテストするソフトウェアエンジニアリング手法です。この記事では、継続的インテグレーションの一般的な概念と、Xamarin プロジェクトとの継続的な統合に使用できるいくつかのオプションについて説明します。Continuous Integration is a software engineering practice in which an automated build compiles and optionally tests an app when code is added or changed by developers in the project's version control repository. This article will discuss the general concepts of Continuous Integration and some of the options available for Continuous Integration with Xamarin projects.

これは、開発者が並行して作業するためのソフトウェアプロジェクトに共通しています。It is common on software projects for developers to work in parallel. ある時点で、このような並列処理のすべてを、最終的な成果物を構成する1つのコードベースに統合する必要があります。At some point, it is necessary to integrate all of these parallel streams of work into one codebase that makes up the final product. ソフトウェア開発の初期段階では、この統合がプロジェクトの最後に実行されていましたが、これは困難でリスクの高いプロセスでした。In the early days of software development, this integration was performed at the end of a project, which was a difficult and risky process.

継続的インテグレーション (CI) は、開発者がプロジェクトの共有コードリポジトリに変更をチェックインするたびに、開発者のすべての変更を共通のコードベースに継続的にマージすることで、このような複雑さを回避します。Continuous Integration (CI) avoid such complexities by merging every developer's changes into the common code base on a continual basis, usually whenever any developers checks in changes to the project's shared code repository. 各チェックインは自動ビルドをトリガーし、自動テストを実行して、新しく導入されたコードが既存のコードを破壊していないことを確認します。Each check-in triggers an automated build and runs automated tests to verify that the newly introduced code didn’t break any existing code. この方法では、CI によってエラーと問題が即座に発生し、すべてのチームメンバーが互いの作業を確実に最新の状態に保つことができます。In this way, CI surfaces errors and problems immediately and ensures that all team members stay up to date with each other's work. これにより、統一された、安定したコードベースが生成されます。This results in a cohesive and stable codebase.

継続的インテグレーションシステムには、次の2つの主要な部分があります。Continuous integration systems have two main parts:

  • バージョン管理(VC) は、ソース管理またはソースコード管理とも呼ばれ、すべてのプロジェクトのコードを1つの共有リポジトリに統合し、すべてのファイルに対するすべての変更の完全な履歴を保持します。Version Control – Version Control (VC), also called source control or source code management, consolidates all of a project's code into a single shared repository and keeps a full history of every change to every file. このリポジトリ (多くの場合、メインラインまたはマスターブランチと呼ばれます) には、最終的にアプリの運用バージョンまたはリリースバージョンをビルドするために使用されるソースコードが含まれています。This repository, often referred to as the mainline or master branch, contains the source code that will ultimately be used to build the production or release version of the app. このタスクには多くのオープンソースおよび商用製品があります。通常、チームまたは個人は、コードのコピーをセカンダリブランチにフォークすることができます。これにより、マスターブランチへのリスクなしに広範な変更を行ったり実験を実施したりすることができます。There are many open source and commercial products for this task, which typically allow teams or individuals to fork a copy of the code into secondary branches where they can make extensive changes or conduct experiments without risk to the master branch. セカンダリブランチの変更が検証されると、その変更をすべてマスターブランチにマージして戻すことができます。Once changes in a secondary branch are validated, they can then be all together merged back into the master branch.
  • 継続的インテグレーションサーバー –継続的インテグレーションサーバーは、プロジェクトのすべてのアーティファクト (ソースコード、画像、ビデオ、データベース、自動テストなど) を収集し、アプリをコンパイルし、自動テストを実行します。Continuous Integration Server – The Continuous Integration Server is responsible for collecting all of a project's artifacts (source code, images, videos, databases, automated tests, etc.), compiling the app, and running the automated tests. ここでも、多数のオープンソースおよび商用 CI サーバーツールがあります。Again, there are many open source and commercial CI server tools.

通常、開発者はワークステーション上に1つ以上のブランチの作業コピーを作成します。作業は最初に完了します。Developers typically have a working copy of one or more branches on their workstations, where work is initially done. 適切な一連の作業が完了すると、変更は適切な分岐に "チェックイン" または "コミット済み" になり、他の開発者の作業コピーに反映されます。Once an appropriate set of work is complete, the changes are "checked into" or "committed" to the appropriate branch, which propagates them to the working copies of other developers. これは、チームがすべて同じコードで作業していることを確認する方法です。This is how a team ensures that they're all working on the same code.

さらに、継続的インテグレーションでは、変更をコミットする操作によって、CI サーバーはプロジェクトをビルドし、自動テストを実行してソースコードの正確性を検証します。Again, with continuous integration, the act of committing changes causes the CI server to build the project and run automated tests to verify the correctness of the source code. ビルドエラーまたはテストの失敗が発生した場合、CI サーバーは、担当開発者に (電子メール、IM、Twitter、Growl などを使用して) 通知し、問題を解決できるようにします。If there are build errors or test failures, a CI server notifies the responsible developer (via email, IM, Twitter, Growl, etc.) so he or she can correct the problem. ("ゲートチェックイン" と呼ばれるエラーがある場合、CI サーバーはコミットを拒否することもできます)。(CI servers can even refuse the commit if there are failures, which is called a "gated check-in".)

このプロセスを次の図に示します。The following diagram illustrates this process:

モバイルアプリでは、継続的インテグレーションのための固有の課題が生じます。Mobile apps introduce unique challenges for continuous integration. アプリには、物理デバイスでのみ使用できる GPS やカメラなどのセンサーが必要になる場合があります。Apps may require sensors such as the GPS or camera that are only available on physical devices. さらに、シミュレーターまたはエミュレーターはハードウェアの近似値であり、問題を隠すか不明瞭にすることができます。In addition, simulators or emulators are only an approximation of hardware and may conceal or obscure problems. 最終的には、実際のハードウェアでモバイルアプリをテストして、本当に顧客の準備が整っていることを確信する必要があります。In the end, it's necessary to test a mobile app on real hardware to be confident that it's truly customer-ready.

App Center テストでは、数百の物理デバイス上で直接アプリをテストすることで、この問題に対処します。The App Center Test addresses this particular problem by testing apps directly on hundreds of physical devices. 開発者は、強力な UI テストを可能にする自動化された受け入れテストを作成します。Developers write automated acceptance tests, which allow for powerful UI testing. これらのテストが App Center にアップロードされると、CI サーバーは、次の図に示すように CI プロセスの一部として自動的に実行できます。Once these tests are uploaded to App Center, the CI server can run them automatically as part of a CI process as shown in the following diagram:

継続的インテグレーションのコンポーネントComponents of Continuous Integration

CI をサポートするように設計された商用およびオープンソースツールの広範なエコシステムが用意されています。There is an extensive ecosystem of commercial and open-source tools designed to support CI. このセクションでは、最も一般的なもののいくつかについて説明します。This section explains a few of the most common ones.

バージョン コントロールVersion Control

Azure DevOps と Team Foundation ServerAzure DevOps and Team Foundation Server

Azure DevOps and Team Foundation Server (TFS) は、継続的インテグレーションビルドサービス、タスク追跡、アジャイル計画およびレポートツール、バージョン管理を行うための Microsoft のコラボレーションツールです。Azure DevOps and Team Foundation Server (TFS) are Microsoft's collaborative tools for continuous integration build services, task tracking, agile planning and reporting tools, and version control. バージョン管理を使用すると、Azure DevOps および TFS は、独自のシステム (Team Foundation バージョン管理または TFVC)、または GitHub でホストされているプロジェクトと連携できます。With version control, Azure DevOps and TFS can work with its own system (Team Foundation Version Control or TFVC) or with projects hosted on GitHub.

  • Azure DevOps は、クラウド経由でサービスを提供します。Azure DevOps provides services via the cloud. 主な利点は、専用のハードウェアまたはインフラストラクチャを必要とせず、どこからでも web ブラウザーや Visual Studio などの一般的な開発ツールを介してアクセスできることです。地理的に分散しているチームにとって魅力があります.Its primary advantage is that it requires no dedicated hardware or infrastructure and can be accessed from anywhere through web browsers and through popular development tools such as Visual Studio, making it appealing for teams that are geographically distributed. 5人の開発者のチームにとっては無料です。その後、拡大するチームに対応するために追加のライセンスを購入できます。It is free for teams of five developers or less, after which additional licenses can be purchased to accommodate a growing team.
  • TFS は、オンプレミスの Windows サーバー向けに設計されており、ローカルネットワークまたはそのネットワークへの VPN 接続を介してアクセスします。TFS is designed for on-premises Windows servers and accessed through a local network or a VPN connection to that network. 主な利点は、ビルドサーバーの構成を完全に制御し、必要な追加のソフトウェアやサービスをインストールできることです。Its primary advantage is that you fully control the configuration of the build servers and can install whatever additional software or services are needed. TFS には、小規模なチーム向けの無料のエントリレベルの Express edition があります。TFS has a free entry-level Express edition for small teams.

TFS と Azure DevOps はどちらも Visual Studio と密接に統合されており、開発者は1つの IDE から快適に多くのバージョンコントロールと CI タスクを実行できます。Both TFS and Azure DevOps are tightly integrated with Visual Studio and allow developers to perform many version control and CI tasks from within the comfort of a single IDE. Eclipse 用の Team Explorer Everywhere プラグイン (下記参照) も使用できます。The Team Explorer Everywhere plugin for Eclipse (see below) is also available. Visual Studio for Mac には、TFVC のプレビューが用意されています。Visual Studio for Mac has a preview of TFVC available.

Azure DevOps パイプラインでは、Xamarin プロジェクトが直接サポートされており、対象とするプラットフォームごとにビルド定義を作成します (Android、IOS、Windows)。Azure DevOps Pipelines has direct support for Xamarin projects, within which you create a build definition for each platform you wish to target (Android, iOS, and Windows). 各ビルド定義には、適切な Xamarin ライセンスが必要です。The appropriate Xamarin license is needed for each build definition. この目的のために、Xamarin 対応のローカルの TFS ビルドサーバーを Azure DevOps に接続することもできます。It's also possible to connect a local, Xamarin-capable TFS build server to Azure DevOps for this purpose. このセットアップでは、Azure DevOps のキューに登録されているビルドがローカルサーバーに委任されます。With this setup, builds that are queued to Azure DevOps will be delegated to the local server. 詳細については、「ビルドエージェントとリリースエージェント」を参照してください。For details, refer to Build and release agents. または、Jenkins やチーム City など、別のビルドツールを使用することもできます。Alternately, you can use another build tool such as Jenkins or Team City.

Visual Studio、Azure DevOps、Team Foundation Server のすべてのアプリケーションライフサイクル管理 (ALM) 機能の完全な概要については、「 DevOps With Xamarin Apps」を参照してください。A complete summary of all Application Lifecycle Management (ALM) features of Visual Studio, Azure DevOps, and Team Foundation Server, see DevOps with Xamarin Apps.

Team Explorer EverywhereTeam Explorer Everywhere

Team Explorer Everywhereは、Visual Studio の外部で開発するチームに Team Foundation Server と Azure DevOps の機能をもたらします。Team Explorer Everywhere brings the power of Team Foundation Server and Azure DevOps to teams developing outside of Visual Studio. これにより、開発者は、Eclipse または OS X および Linux 用のクロスプラットフォームコマンドラインクライアントから、オンプレミスまたはクラウド内のチームプロジェクトに接続できます。It allows developers to connect to team projects on premises or in the cloud from Eclipse or the cross-platform command line client for OS X and Linux. Team Explorer Everywhere を使用すると、Windows 以外のプラットフォームのバージョンコントロール (Git を含む)、作業項目、およびビルド機能にフルアクセスできます。Team Explorer Everywhere provides full access to version control (including Git), work items, and build capabilities for non-Windows platforms.

GitGit

Gitは、Linux カーネルのソースコードを管理するために最初に開発された、広く普及しているオープンソースのバージョン管理ソリューションです。Git is a popular open source version control solution that was originally developed to manage the source code for the Linux kernel. これは、あらゆる規模のソフトウェアプロジェクトでよく使用される、非常に高速で柔軟なシステムです。It is a very fast, flexible system that is popular with software projects of all sizes. インターネットアクセスが不十分な単一の開発者から、世界中の大規模なチームに簡単に拡張できます。It easily scales from single developers with poor Internet access to large teams that span the globe. Git では、ブランチを非常に簡単にすることもできます。これにより、最小限のリスクで開発の並列ストリームを奨励することができます。Git also makes branching very easy, which in turn can encourage parallel streams of development with minimal risk.

Git は、web ブラウザー、または Linux、Mac OSX、Windows で実行されているGUI クライアントを使用して完全に動作できます。Git can operate entirely through web browsers, or GUI clients that run on Linux, Mac OSX, and Windows. パブリックリポジトリでは無料です。プライベートリポジトリには有料プランが必要です。It is free for public repositories; private repositories require a paid plan.

現在のバージョンの Visual Studio for Windows と Mac では、Git のネイティブサポートが提供されています。Current versions of Visual Studio for Windows and Mac provide native support for Git. Microsoft では、以前のバージョンの Visual Studio でGit のダウンロード可能な拡張機能を提供しています。Microsoft provides a downloadable extension for Git for older versions of Visual Studio. 前述のように、Azure DevOps と TFS では、TFVC ではなくバージョン管理に Git を使用できます。As noted above, Azure DevOps and TFS can use Git for version control instead of TFVC.

破壊Subversion

Subversion (SVN) は、2000以降に使用されていた、広く普及しているオープンソースのバージョン管理システムです。Subversion (SVN) is a popular, open source version control system that has been in use since 2000. SVN は、OS X、Windows、FreeBSD、Linux、および Unix のすべての最新バージョンで実行されます。SVN runs on all modern versions of OS X, Windows, FreeBSD, Linux, and Unix. Visual Studio for Mac は、SVN をネイティブでサポートしています。Visual Studio for Mac has native support for SVN. SVN サポートを Visual Studio に導入するサードパーティ製の拡張機能があります。There are third party extensions that bring SVN support to Visual Studio.

継続的インテグレーション環境Continuous Integration Environments

継続的インテグレーション環境をセットアップするということは、バージョンコントロールシステムとビルドサービスを組み合わせることです。Setting up a continuous integration environment means combining a version control system with a build service. 後者の場合、最も一般的な2つの方法は次のとおりです。For the latter, the two most common ones are:

  • Azure Pipelinesは、Azure DEVOPS と TFS のビルドシステムです。Azure Pipelines is the build system of Azure DevOps and TFS. これは Visual Studio と密接に統合されているため、開発者がビルドをトリガーし、自動的にテストを実行し、結果を確認するのに便利です。It is tightly integrated with Visual Studio, which makes it convenient for developers to trigger builds, automatically run tests, and see the results.
  • Jenkins は、あらゆる種類のソフトウェア開発をサポートするプラグインの豊富なエコシステムを備えたオープンソースの CI サーバーです。Jenkins is an open-source CI server with a rich ecosystem of plugins to support all kinds of software development. Windows および Mac OS X で実行されます。 Jenkins は特定の IDE と統合されていません。It runs on Windows and Mac OS X. Jenkins is not integrated with any specific IDE. 代わりに、web インターフェイスを使用して構成および管理されます。Instead, it is configured and managed via a web interface. また、Jenkins CI は簡単にインストールして構成できるので、小規模なチームにとって魅力があります。Jenkins CI is also easy to install and configure which makes it appealing to small teams.

TFS/Azure DevOps を単独で使用することも、次のセクションで説明するように、Jenkins と TFS/Azure DevOps または Git を組み合わせて使用することもできます。You can use TFS/Azure DevOps by itself, or you can use Jenkins in combination with TFS/Azure DevOps or Git as described in the following sections.

Azure DevOps と Team Foundation ServerAzure DevOps and Team Foundation Server

既に説明したように、Azure DevOps と Team Foundation Server には、バージョンコントロールとビルドサービスの両方が用意されています。As discussed, Azure DevOps and Team Foundation Server provides both version control and build services. ビルドサービスは、ターゲットプラットフォームごとに Xamarin Business または Enterprise のライセンスを常に必要とします。Build services always require a Xamarin Business or Enterprise license for each target platform.

Azure DevOps では、ターゲットプラットフォームごとに個別のビルド定義を作成し、そこに適切なライセンスを入力します。With Azure DevOps, you create a separate build definition for each target platform and enter the appropriate license there. 構成が完了すると、Azure DevOps はクラウドでビルドとテストを実行します。Once configured, Azure DevOps will run builds and tests in the cloud. 詳細については、「 Azure Pipelines 」を参照してください。See Azure Pipelines for more details.

Team Foundation Server では、特定のターゲットプラットフォームに合わせてビルドコンピューターを次のように構成します。With Team Foundation Server, you configure a build machine as follows for specific target platforms:

  • Android と Windows: Visual Studio と Xamarin ツール (Android と Windows の両方) をインストールし、Xamarin のライセンスでを構成します。Android and Windows: Install Visual Studio and the Xamarin tools (for Android and Windows both) and configure with your Xamarin licenses. また、Android SDK を TFS ビルドエージェントが検出できるサーバー上の共有の場所に移動することも必要です。It is also necessary to move the Android SDK to a shared location on the server where the TFS build agent can find it. 詳細については、「 TFVC の構成」を参照してください。For details, see Configuring TFVC.
  • iOS と Xamarin: 適切なライセンスを使用して、Visual Studio と Xamarin ツールを Windows server にインストールします。iOS and Xamarin: Install Visual Studio and the Xamarin tools on the Windows server with the appropriate license. 次に、ネットワークからアクセス可能な Mac OS X マシンに Visual Studio for Mac をインストールします。これはビルドホストとして機能し、最終的なアプリケーションパッケージを作成します (iOS の場合は IPA、OS X の場合は APP)。Then install Visual Studio for Mac on a network-accessible Mac OS X machine, which will serve as a build host and create the final app package (IPA for iOS, APP for OS X).

次の図は、このようになっていることを示しています。The following diagram illustrates this topography:

また、ローカルの TFS サーバーを Azure DevOps プロジェクトにリンクして、Azure DevOps のビルドがローカルサーバーに委任されるようにすることもできます。It is also possible to link a local TFS server to an Azure DevOps project so that Azure DevOps builds are delegated to the local server. 詳細については、「ビルドエージェントとリリースエージェント」を参照してください。For details, see Build and release agents.

Azure DevOps と JenkinsAzure DevOps and Jenkins

Jenkins を使用してアプリをビルドする場合は、Azure DevOps または Team Foundation Server にコードを保存し、CI ビルドに対して Jenkins を引き続き使用することができます。If you use Jenkins to build your apps, you can store your code in Azure DevOps or Team Foundation Server and continue to use Jenkins for your CI builds. チームプロジェクトの Git リポジトリにコードをプッシュするとき、または TFVC にコードをチェックインするときに、Jenkins ビルドをトリガーできます。You can trigger a Jenkins build when you push code to your team project's Git repository or when you check code in to TFVC. 詳細については、「 Jenkins With Azure DevOps」を参照してください。For details, see Jenkins with Azure DevOps.

Git と JenkinsGit And Jenkins

もう1つの一般的な CI 環境は、完全に OS X ベースにすることができます。Another common CI environment can be entirely OS X based. このシナリオでは、ソースコード管理に Git を使用し、ビルドサーバーに Jenkins を使用します。This scenario involves using Git for source code control and Jenkins for the build server. これらはどちらも、Visual Studio for Mac がインストールされている1台の Mac OS X コンピューター上で実行されています。Both of these are running on a single Mac OS X computer with Visual Studio for Mac installed. これは、前のセクションで説明した Azure DevOps + Jenkins 環境とよく似ています。This is very similar to the Azure DevOps + Jenkins environment discussed in the previous section: