Xamarin との継続的インテグレーションの概要

  • [アーティクル]

継続的インテグレーションは、プロジェクトのバージョン管理リポジトリの開発者がコードを追加または変更したときに、自動ビルドがコンパイルされ、必要に応じてアプリをテストするソフトウェア エンジニアリングプラクティスです。 この記事では、継続的インテグレーションの一般的な概念と、Xamarin プロジェクトとの継続的インテグレーションに使用できるオプションについて説明します。

開発者が並行して作業するためのソフトウェア プロジェクトでは一般的です。 ある時点で、これらすべての並列作業ストリームを、最終的な製品を構成する 1 つのコードベースに統合する必要があります。 ソフトウェア開発の初期の頃、この統合はプロジェクトの最後に実行されましたが、これは困難で危険なプロセスでした。

継続的インテグレーション (CI) は、すべての開発者の変更を共通コード ベースに継続的にマージすることで、このような複雑さを回避します。通常は、開発者がプロジェクトの共有コード リポジトリへの変更をチェックインするたびに行います。 各チェックは、自動ビルドをトリガーし、自動テストを実行して、新しく導入されたコードが既存のコードを中断していないことを確認します。 このようにして、CI はエラーや問題を直ちに表示し、すべてのチーム メンバーが互いの作業を常に最新の状態に保ちます。 これにより、まとまりのある安定したコードベースが得られます。

継続的インテグレーション システムには、次の 2 つのメイン部分があります。

  • バージョン管理 – バージョン管理 (VC) は、ソース管理またはソース コード管理とも呼ばれ、プロジェクトのすべてのコードを 1 つの共有リポジトリに統合し、すべてのファイルに対するすべての変更の完全な履歴を保持します。 このリポジトリは、多くの場合 、メインライン ブランチと呼ばれ、最終的にアプリの実稼働バージョンまたはリリース バージョンのビルドに使用されるソース コードを含みます。 このタスクには多くのオープンソースおよび商用製品があります。通常、チームまたは個人はコードのコピーをセカンダリ ブランチにフォークできます。このブランチでは、大規模な変更を加えたり、メイン ブランチに対するリスクなしに実験を行ったりできます。 セカンダリ ブランチの変更を検証したら、その変更をすべて メイン ブランチにマージし直すことができます。
  • 継続的インテグレーション サーバー – 継続的インテグレーション サーバーは、プロジェクトのすべての成果物 (ソース コード、画像、ビデオ、データベース、自動テストなど) の収集、アプリのコンパイル、自動テストの実行を担当します。 ここでも、多くのオープンソースおよび商用 CI サーバー ツールがあります。

開発者は通常、作業が最初に行われるワークステーション上の 1 つ以上のブランチの作業コピーを持っています。 適切な作業セットが完了すると、変更は適切なブランチに "チェックイン" または "コミット" され、他の開発者の作業コピーに反映されます。 これは、チームが全員が同じコードで作業していることを保証する方法です。

繰り返しになりますが、継続的インテグレーションでは、変更をコミットすると、CI サーバーはプロジェクトをビルドし、自動テストを実行してソース コードの正確性を確認します。 ビルド エラーやテスト エラーが発生した場合、CI サーバーは責任ある開発者に (電子メール、IM、Twitter、Growl などを介して) 通知して、問題を修正できるようにします。 (CI サーバーは、"ゲート チェックイン" と呼ばれる障害が発生した場合でもコミットを拒否できます)。

次の図は、このプロセスを示しています。

この図は、このプロセスを示しています

モバイル アプリでは、継続的インテグレーションに固有の課題が導入されています。 アプリでは、GPS などのセンサーや、物理デバイスでのみ使用できるカメラが必要になる場合があります。 さらに、シミュレーターまたはエミュレーターはハードウェアの近似に過ぎません。問題を隠したり隠したりすることがあります。 最終的には、実際のハードウェアでモバイル アプリをテストし、真の顧客対応であることを確信する必要があります。

App Center テストでは、数百の物理デバイスでアプリを直接テストすることで、この特定の問題に対処します。 開発者は、強力な UI テストを可能にする自動受け入れテストを作成します。 これらのテストが App Center にアップロードされると、次の図に示すように、CI サーバーは CI プロセスの一部として自動的に実行できます。

これらのテストが App Center にアップロードされると、CI サーバーは、この図に示すように CI プロセスの一部として自動的に実行できます

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

CI をサポートするように設計された商用ツールとオープンソース ツールの広範なエコシステムがあります。 このセクションでは、最も一般的なものをいくつか説明します。

バージョン コントロール

Azure DevOps と Team Foundation Server

Azure DevOps と Team Foundation Server (TFS) は、継続的インテグレーション ビルド サービス、タスク追跡、アジャイル計画およびレポート ツール、バージョン管理のための Microsoft のコラボレーション ツールです。 バージョン管理を使用すると、Azure DevOps と TFS は、独自のシステム (Team Foundation バージョン管理または TFVC) または GitHub でホストされているプロジェクトを操作できます。

  • Azure DevOps は、クラウド経由でサービスを提供します。 主な利点は、専用のハードウェアやインフラストラクチャを必要とせず、Web ブラウザーや Visual Studio などの一般的な開発ツールを使用してどこからでもアクセスできることです。これにより、地理的に分散されたチームにとって魅力的です。 5 人以下の開発者のチームは無料です。その後、成長するチームに対応するために追加のライセンスを購入できます。
  • TFS は、オンプレミスの Windows サーバー用に設計されており、ローカル ネットワークまたはそのネットワークへの VPN 接続を介してアクセスされます。 その主な利点は、ビルド サーバーの構成を完全に制御し、必要な追加のソフトウェアやサービスをインストールできることです。 TFS には、小規模なチーム向けの無料のエントリ レベルの Express エディションがあります。

TFS と Azure DevOps の両方が Visual Studio と緊密に統合されており、開発者は 1 つの IDE の快適な範囲内から多くのバージョン管理と CI タスクを実行できます。 Eclipse 用のTeam Explorer Everywhere プラグイン (下記参照) も利用できます。 Visual Studio for Mac TFVC のプレビューが利用可能です。

Azure DevOps Pipelines は Xamarin プロジェクトを直接サポートしており、その中でターゲットにするプラットフォーム (Android、iOS、Windows) ごとにビルド定義を作成します。 ビルド定義ごとに適切な Xamarin ライセンスが必要です。 この目的のために、ローカルの Xamarin 対応 TFS ビルド サーバーを Azure DevOps に接続することもできます。 このセットアップでは、Azure DevOps にキューに登録されているビルドがローカル サーバーに委任されます。 詳細については、「 ビルド エージェントとリリース エージェント」を参照してください。 または、Jenkins や Team City などの別のビルド ツールを使用することもできます。

Visual Studio、Azure DevOps、Team Foundation Server のすべてのアプリケーション ライフサイクル管理 (ALM) 機能の完全な概要については、「 Xamarin Apps を使用した DevOps」を参照してください。

Team Explorer Everywhere

Team Explorer Everywhereは、Visual Studio の外部で開発するチームに Team Foundation Server と Azure DevOps の機能をもたらします。 これにより、開発者は、Eclipse または OS X および Linux 用のクロスプラットフォーム コマンド ライン クライアントから、オンプレミスまたはクラウドのチーム プロジェクトに接続できます。 Team Explorer Everywhereは、バージョン管理 (Git を含む)、作業項目、および Windows 以外のプラットフォームのビルド機能へのフル アクセスを提供します。

Git

Git は、Linux カーネルのソース コードを管理するために最初に開発された、一般的なオープンソースバージョン管理ソリューションです。 それはあらゆるサイズのソフトウェア プロジェクトで普及している非常に速く、適用範囲が広いシステムである。 インターネットへのアクセスが悪い単一の開発者から、世界中の大規模なチームに簡単にスケーリングできます。 Git を使用すると、分岐が非常に簡単になり、リスクを最小限に抑えた開発の並列ストリームが促進されます。

Git は、Web ブラウザー、または Linux、Mac OSX、および Windows 上で実行される GUI クライアント を介して完全に動作できます。 パブリックリポジトリは無料です。プライベート リポジトリには 有料プランが必要です。

現在のバージョンの Visual Studio for Windows と Mac では、Git のネイティブ サポートが提供されています。 Microsoft では、以前のバージョンの Visual Studio 用の Git 用のダウンロード可能な拡張機能 を提供しています。 前述のように、Azure DevOps と TFS では、TFVC ではなくバージョン管理に Git を使用できます。

Subversion

Subversion (SVN) は、2000 年から使用されている一般的なオープンソースバージョン管理システムです。 SVN は、OS X、Windows、FreeBSD、Linux、Unix のすべての最新バージョンで実行されます。 Visual Studio for Macには、SVN のネイティブ サポートがあります。 Visual Studio に SVN のサポートをもたらすサード パーティの拡張機能があります。

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

継続的インテグレーション環境を設定するということは、バージョン管理システムとビルド サービスを組み合わせることを意味します。 後者の場合、最も一般的なものは次の 2 つです。

  • Azure Pipelines は、Azure DevOps と TFS のビルド システムです。 Visual Studio と緊密に統合されているため、開発者はビルドをトリガーし、テストを自動的に実行し、結果を確認するのに便利です。
  • Jenkins は、あらゆる種類のソフトウェア開発をサポートするプラグインの豊富なエコシステムを備えたオープンソースの CI サーバーです。 Windows および Mac OS X で実行されます。Jenkins は特定の IDE と統合されていません。 代わりに、Web インターフェイスを介して構成および管理されます。 Jenkins CI はインストールと構成も簡単で、小規模なチームにとって魅力的です。

TFS/Azure DevOps を単独で使用することも、次のセクションで説明するように、Jenkins を TFS/Azure DevOps または Git と組み合わせて使用することもできます。

Azure DevOps と Team Foundation Server

説明したように、Azure DevOps と Team Foundation Server には、バージョン管理とビルド サービスの両方が用意されています。 ビルド サービスには、ターゲット プラットフォームごとに常に Xamarin Business または Enterprise ライセンスが必要です。

Azure DevOps では、ターゲット プラットフォームごとに個別のビルド定義を作成し、そこに適切なライセンスを入力します。 構成が完了すると、Azure DevOps はクラウドでビルドとテストを実行します。 詳細については、「 Azure Pipelines 」を参照してください。

Team Foundation Server では、特定のターゲット プラットフォームに対して次のようにビルド マシンを構成します。

  • Android と Windows: Visual Studio と Xamarin ツール (Android と Windows の両方用) をインストールし、Xamarin ライセンスを使用して構成します。 また、TFS ビルド エージェントが見つけることができるサーバー上の共有場所に Android SDK を移動する必要もあります。 詳細については、「 TFVC の構成」を参照してください。
  • iOS と Xamarin: 適切なライセンスを使用して、Visual Studio と Xamarin ツールを Windows サーバーにインストールします。 次に、ネットワークにアクセスできる Mac OS X マシンにVisual Studio for Macをインストールします。これはビルド ホストとして機能し、最終的なアプリ パッケージ (iOS の場合は IPA、OS X の場合は APP) を作成します。

次の図は、この地形を示しています。

この図は、この地形を示しています

ローカル TFS サーバーを Azure DevOps プロジェクトにリンクして、Azure DevOps ビルドをローカル サーバーに委任することもできます。 詳細については、「 ビルド エージェントとリリース エージェント」を参照してください。

Azure DevOps と Jenkins

Jenkins を使用してアプリをビルドする場合は、コードを Azure DevOps または Team Foundation Server に格納し、CI ビルドに引き続き Jenkins を使用できます。 Jenkins ビルドは、チーム プロジェクトの Git リポジトリにコードをプッシュするとき、または TFVC にコードをチェックするときにトリガーできます。 詳細については、「 Azure DevOps を使用した Jenkins」を参照してください。

Jenkins を使用してアプリをビルドする場合は、Azure DevOps または Team Foundation Server にコードを格納し、CI ビルドに Jenkins を引き続き使用できます

Git と Jenkins

もう 1 つの一般的な CI 環境は、完全に OS X ベースです。 このシナリオでは、ソース コード管理に Git を使用し、ビルド サーバーに Jenkins を使用します。 どちらも、Visual Studio for Macがインストールされている単一の Mac OS X コンピューターで実行されています。 これは、前のセクションで説明した Azure DevOps + Jenkins 環境によく似ています。

これは、前のセクションで説明した Azure DevOps + Jenkins 環境によく似ています

重要

Jenkins は Microsoft ではサポートされていません。