前書き

Xcode 9より前は、Appleの継続的インテグレーションツールの使用は、追加のmacOSServerアプリの購入とインストールを必要とする退屈で複雑なプロセスでした。これは多くを導きました 開発者 iOSプロジェクトの継続的インテグレーションのアイデアを放棄するか、サードパーティのソリューションに頼って、成功のレベルを大きく変えます。

ただし、2017年9月にXcode 9.0がリリースされた後、自動コード署名のオプションを含め、プロセスが大幅に簡素化され、Xcodeに完全に統合されました。したがって、追加のアプリやツールは必要ありません。

のようなサードパーティのソリューションが 追い越し車線 、 ブルーピル などは非常に役立ち、多くのうなり声を上げることができます。この記事では、XcodeとAppleのツールを単独で使用する機能について説明します。 継続的インテグレーションのニーズ 。また、多くの人にとって問題になることが多いため、手動のコード署名も使用します。また、複数のビルド構成に関しては、自動署名も最適なソリューションではない傾向があります。

注意： この記事はXcode9.4.1に基づいており、iOSアプリの開発に焦点を当てていますが、その多くはXcode 10（現在ベータ5ビルドとして利用可能）とmacOSアプリの開発に適用できます。

Xcodeサーバーのセットアップ

Xcode 9は、実際の統合プロセスを簡素化するだけでなく、Xcodeサーバーのセットアッププロセスも簡素化しました。

anglejsトークン認証WebAPI

CIサーバーとして指定されているmacOSマシンでXcodeアプリを起動し、[設定]を開きます。

と呼ばれる最後のタブに移動します サーバーとボット 。

右上隅のスイッチをクリックして、Xcodeサーバーの機能をオンにします。次に、このマシンでビルドスクリプトを実行および実行するユーザーを選択するように求められます。既存のユーザーを使用するのではなく、この目的のためだけに専用のユーザーを用意することをお勧めします。

Xcodeボットを実行するには、このユーザーがシステムにログインしている必要があることに注意してください。ログイン後、ユーザー名の横に緑色の円が表示されます。

それでおしまい！ Xcodeボットを詳しく見てみましょう。

Xcodeボットを構成する方法

これで、このサーバーで実行するXcodeボットの構成を開始する準備が整いました。これは、サーバーと同じネットワークに接続されている任意の開発マシンで実行できます。

開発マシンでXcodeを開き、をクリックします Xcode>設定 トップメニューから。次に、に移動します アカウント タブをクリックし、 + 左下隅のアイコン。表示されるダイアログからXcodeサーバーを選択します。

ボットを作成するには、Xcodeでプロジェクトを開き、 製品>ボットの作成… トップメニューからのオプション。ボットのセットアップにはいくつかの手順があり、次のセクションでそれらについて説明します。

アプリ配布の自動化

iOSアプリビルド自動化の最も頻繁なアプリケーションの1つは、TestFlight、FabricなどのiOS配布プラットフォームにアプリをアップロードするようにボットを構成することです。

前に説明したように、この記事では、App Store Connectへのアップロードと、Xcodeサーバーからの直接ダウンロードについてのみ説明します。これらはiOSアプリ配布用のAppleのネイティブツールです。

javascriptは日付をUTCに変換します

Xcodeを使用したAppStoreConnectの配布

ボットを構成する前に、アプリ開発プロジェクトのバンドルIDと一致するApp StoreConnectアプリレコードがあることを確認してください。また、各ビルドには、ビルドバージョンとビルド番号で構成される一意の識別子が必要であることに注意してください。後でXcodeボットの設定について説明するときに、これらの条件が満たされていることを確認する方法について説明します。

ステップ1： 正しいビルド構成をセットアップすることは、必要なものを取得するための重要なステップです。 App StoreConnectにアップロードするアプリを作成するスキームと構成を選択してください。これには、ビルド構成で、チームのApple Developerポータル（コード署名に使用）およびApp Store Connectポータル（アプリの自動アップロードに使用）に登録されている適切なバンドルIDが使用されていることを確認することが含まれます。 。

ステップ2： 「構成」タブを表示したまま、エクスポートオプションを指定する必要があります。エクスポートオプションのプロパティリストについて説明しますので、[カスタムエクスポートオプションのリストを使用する]が選択されていることを確認してください。

ステップ3： 今こそ、エクスポートオプションのプロパティリストを作成するときです。 xcodebuild --helpと入力すると、このファイルで使用されるキーの完全なリストが利用可能になりますが、このボット構成で使用されるキーについては、ここで説明します。

• compileBitcode –ビットコードは、アプリのソースコードに対するAppleの暫定出力形式です。つまり、特定のアーキテクチャのマシンコードにコンパイルされる前にソースコードが変換される形式です。これは、命令セットで最適化が行われた場合にさらに最適化できる単一のコードコンテナーを持ち、この同じ形式から将来のアーキテクチャーにコンパイルできるようにすることを目的としています。ただし、これはアプリケーションに影響を与えません。有効にするかどうかはあなた次第です。
• method –この引数は、エクスポートする製品の種類を指定します。 Appleは、指定されたオーディエンスによって製品を区別します— 開発 プロビジョニングプロファイルで指定されたデバイスにのみインストールできます。 企業 誰でもインストールできますが、アプリを実行する前に、この開発プロファイルを明示的に信頼する必要があります。 アプリストア AppStoreまたはAppStore Connectに配布するためのものなので、この値を使用します。
• provisioningProfiles –これは自明です。ただし、ここで注意すべき点がいくつかあります。エクスポートオプションのプロパティリストのプロビジョニングプロファイルは、 キー 製品のバンドルIDに対応し、 値 コード署名に使用されるプロビジョニングプロファイルの名前に対応します。
• signingCertificate –もう1つの自明の議論。このフィールドの値は、完全な証明書名またはSHA-1ハッシュにすることができます。
• teamID –もう1つの自明の議論。これは、AppleDeveloperプログラムにサインアップしたときにAppleが組織に発行した10文字の長さの識別子です。
• uploadBitcode –ビットコードをアップロードして（コンパイルすることを選択した場合）、AppStoreConnectで使用して新しい最適化されたビルドまたは将来のアーキテクチャ用のビルドを生成できるようにするかどうか。
• uploadSymbols –デバッグシンボルをアップロードして、メモリダンプとアセンブリスタックだけでなく、意味のあるクラッシュレポートを取得できるようにします。

したがって、エクスポートオプションのプロパティリストは次のようになります。

compileBitcode method app-store provisioningProfiles com.bundle.id ProvisioningProfileName signingCertificate Signing Certificate Exact Name or SHA-1 hash value teamID ?????????? uploadBitcode uploadSymbols

ステップ4： 作成した.plistをエクスポートオプションのプロパティリストとして選択します。

ステップ5： 次は「スケジュール」タブです。好みに応じて設定します。

ステップ6： [署名]タブで、[Xcodeサーバーに証明書とプロファイルの管理を許可する]オプションをオフにし、一致する署名証明書とプロビジョニングプロファイルを自分でアップロードします。 証明書とプロファイル ページ。

ステップ7： ザ・ デバイス アプリをテストするのではなくアップロードするため、タブはそのままにしておく必要があります。

ステップ8： ザ・ 引数 タブを使用すると、ビルドまたは統合前および統合後のスクリプトで使用できるxcodebuild引数または環境変数を明示的に設定できます。

ステップ9： 最後に、 トリガー タブ。これは、Xcode継続的インテグレーションボットを構成する際の最後のタブでもあります。これは、Xcodeサーバーの兵器庫の中で最も強力なツールです。手始めに、統合前のスクリプトとして次の2つのコマンドを追加したいと思います。

#!/bin/sh set printenv

最初のものは、Xcodeサーバーが現在の統合実行で使用するすべての変数とそれらの値を出力します。 2つ目は、すべての環境変数とその値を出力します。予想どおり、これはスクリプトのデバッグに役立つ可能性があるため、適切に「デバッグ情報」という名前を付けます。

App Store Connectにアップロードされた各ビルドには、一意のビルドバージョンとビルド番号のペアが必要であることを確認する必要があることを忘れないでください。組み込みのPlistBuddyツールを使用できますが、一意のビルド番号を設定する方法も必要です。 Xcodeサーバーの統合中に常に存在し、便利なことに一意であるものの1つは、自動インクリメントされるため、統合番号です。 「setbuildnumber」という名前の別の統合前スクリプトを次の内容で作成して、毎回一意のビルド番号を確保します。

#!/bin/sh buildNumber=$(/usr/libexec/PlistBuddy -c 'Print CFBundleVersion' '${PROJECT_DIR}/${INFOPLIST_FILE}') buildNumber=$XCS_INTEGRATION_NUMBER /usr/libexec/PlistBuddy -c 'Set :CFBundleVersion $buildNumber' '${PROJECT_DIR}/${INFOPLIST_FILE}'

CocoaPodsを使用していて、PodsディレクトリをDVCSにコミットしないことを選択した場合は、次の内容の統合前スクリプトも含める必要があります。

#!/bin/sh cd $XCS_PRIMARY_REPO_DIR pod install

ステップ10： ほぼ完成しましたが、ビルドをAppStoreConnectにアップロードする場所やアカウントを指定していません。この目的のために、統合後のスクリプトと、アプリケーションローダーと呼ばれる別の組み込みツールを追加します。スクリプトに次のように記述します。

#!/bin/sh /Applications/Xcode.app/Contents/Applications/Application Loader.app/Contents/Frameworks/ITunesSoftwareService.framework/Support/altool --upload-app -f $XCS_PRODUCT -u $TESTFLIGHT_USERNAME -p $TESTFLIGHT_PASSWORD

$XCS_PRODUCTはXcodeサーバー変数であり、現在の統合実行で作成されたアプリへのパスが含まれています。ただし、$TESTFLIGHT_USERNAMEおよび$TESTFLIGHT_PASSWORDシステム変数でもXcodeサーバー変数でもありません。これらはユーザーが設定し、AppleIDとパスワードの値を持っている必要があります。残念ながら、AppleはAppStoreConnectビルドアップロード用のAPIキーを生成するためのサポートを終了しました。これは機密情報であるため、Xcode Serverボット構成ではなく、環境変数としてMacサーバーに直接設定することをお勧めします（独自の情報であると想定）。

Xcodeサーバーの配布

Xcode Server配布ボットは、統合後のスクリプトを除いて、実際にはApp StoreConnect配布の構成と同じ構成を使用します。ただし、アプリケーションをダウンロードしてインストールするのは難しい場合があります。アプリに署名したプロビジョニングプロファイルで、使用しているデバイスにアプリをインストールできることを確認する必要があります。

c ++実行可能ファイル

これが整ったら、iOSデバイスでSafariを開き、サーバーのXcodeサーバーWebダッシュボードに移動する必要があります。たとえば、サーバーの名前が「Macサーバー」の場合、サーバーと同じネットワーク上にある場合は「mac-server-name.local / xcode」にあります。そこには、すべてのXcodeボットのリストとそれらの最新の統合の統計があります。

ダウンロードするアプリをビルドしたものを選択します。次の画面には、2つのボタンがあります。 インストール そして プロフィール 。このサーバーから初めてダウンロードする場合は、をクリックする必要があります プロフィール 信頼できるソースのリストに証明書を追加します。その後、をクリックします インストール 同じページのボタンをクリックすると、iOSの確認ダイアログ「デバイスに*をインストールしてもよろしいですか？」が表示されます。クリックして確認してください はい 、アプリがインストールされ、ホーム画面から実行できるようになります。

ために iOS10.3以降 、「*。localに接続できません」で失敗する理由は、テストデバイスの[設定]で自己署名証明書を手動で信頼する必要があるためです。

次の手順を実行します：

ステップ1： iPhoneのXcodeサーバーのボットページから自己署名証明書をインストールします。

ステップ2： iPhoneに移動します 設定>一般>バージョン情報>証明書の信頼設定 。

ステップ3： セクションでサーバーの自己署名証明書を見つけます ルート証明書の完全な信頼を有効にする 、スイッチをONにします。

ステップ4： Xcodeサーバーのボット統合ページに戻り、をクリックします インストール 。

Xcodeサーバーの自動アプリテスト

Xcodeサーバーのもう1つの優れた用途は、ユニットテストであろうとUIテストであろうと、自動アプリテストです。これを行うには、プロジェクトに適切なターゲットを設定する必要があります。つまり、目標に応じて、ユニットテストまたはUIテストを実行するターゲットが必要です。

Pythonでクラス変数を変更する方法

セットアッププロセスは前のプロセスと同じですが、異なるオプションを選択します。最初の大きな違いは 構成 タブ。明らかに、それが私たちの主な目標なので、「分析」と「テスト」ボックスをチェックします。また、このボットを使用して製品をアーカイブしたりエクスポートしたりしないことをお勧めします。同じボット構成でテストと配布の両方を実現することが可能です。ただし、これら2つのシナリオは、出力とスケジュールが異なります。多くの場合、配布はサイクルの最後に実行されます。

スクラム、かんばん、またはその他のフレームワークで作業している場合でも、事前定義された時間駆動型またはイベント駆動型のサイクルがあり、その最後に製品をエクスポートして使用できるようにする必要があります。一方、テストボットはリグレッションに対する最初の防衛線であるため、コミットごとに実行する必要があります。テストボットは明らかに頻繁に実行されるため、これら2つのボットを1つにマージすると、サーバーのディスク領域がすぐに使い果たされる可能性があります。また、各統合が完了するまでにさらに時間がかかります。

これで、[スケジュール]タブに移動します。これについては、前の段落ですでに説明しました。したがって、次に関心のあるトピックはコード署名です。テストターゲットで、プロジェクト設定ページにプロビジョニングプロファイルが不要であると記載されている場合でも、ホストアプリケーションと同じチームと署名証明書を使用するように設定する必要があることに注意してください。これは、シミュレーターだけでなくiOSデバイスでアプリをテストする場合に必要です。この場合は、テストに使用されたiOSデバイスが非アクティブのためにロックされないようにする必要もあります。これにより、通知なしに統合の実行が無期限にハングする可能性があります。

これで、具体的な説明を必要としない[デバイス]タブが表示されます。コードをテストするデバイス（iOSおよびシミュレーター）を1つ、複数、またはすべて選択するだけです。複数のデバイスでテストを並行して実行するか、順次実行するかを確認することもできます。これを設定するには、プロジェクトのニーズ（特定のデバイスのセットをターゲットにしているのか、サポートされているすべてのiOSデバイスをターゲットにしているのか）とサーバーのハードウェアリソースを考慮する必要があります。

に 引数 タブ。組み込みの環境変数のみを使用するため、明示的に指定する必要はありません。

最後に、 トリガー タブでは、1つの統合前スクリプトと1つの統合後スクリプトを紹介します。 1つ目は、問題が発生した場合のデバッグに役立つものです。これは実際に私たちがすでに使用したものです：

#!/bin/sh set printenv

2つ目は、現在の統合で1つ以上のテストが失敗した場合に通知するものです。テストが失敗した場合にのみ実行するように設定されていることを確認してください。そして、次のように入力します。

#!/bin/sh echo '$XCS_TEST_FAILURE_COUNT test(s) failed for $XCS_BOT_NAME bot on build $XCS_INTEGRATION_NUMBER' echo 'You can see bot integration at:' echo 'https://$HOSTNAME/xcode/bots/$XCS_BOT_TINY_ID/integrations/$XCS_INTEGRATION_TINY_ID'

ここで説明する必要があることがいくつかあります。まず、$ HOSTNAME変数は、computer-name.localの形式の値を格納します。明らかに、リンクは、ローカルネットワーク経由でそのサーバーに到達できる場合にのみ機能します。また、このリンクは信頼できない宛先へのhttps接続であるため、このリンクにアクセスすると、ブラウザからセキュリティ警告が表示される可能性があります。最後に、これは「テストの失敗」スクリプトの開始点にすぎません。開発チーム全体にメールを送信するか、APIリクエストまたは最も適切で生産的であると思われるその他の方法でJIRAの問題を開くことができます。

node js express rest api

まとめ

うまくいけば、この記事が、単にアプリを構築するだけでなく、時間をかけてXcodeサーバーの機能を探求することをお勧めします。この投稿では、期待したとおりの方法では役に立たなかったかもしれませんが、目標は、組み込み環境とXcodeサーバー変数を使用してより高いレベルの自動化を実現するオープンマインドな方法を紹介することでした。

より多くの機能を有効にし、Fabric、Bluepill、Fastlaneなど、より多くの作業を実行できるサードパーティのサービスがたくさんあります。ただし、必然的に、サードパーティに依存すると、プロジェクトに新しい依存関係が導入され、単純な場合もあれば複雑な場合もあるセットアップと構成が必要になります。ここで説明する手法では、すべてのMacにすでにインストールされているツールのみが必要であるため、自動ビルドを実行するボットを構成する以外にセットアップ時間は必要ありません。

基本を理解する

Xcodeとは何ですか？

Xcodeは、Appleによって開発された統合開発環境（IDE）であり、Appleデバイス（iOS、tvOS、watchOS、およびmacOS製品）を対象とするプロジェクト用のコード編集およびビルドツールを提供します。

Xcodeサーバーとは何ですか？

Xcodeサーバーは、Xcodeにバンドルされているツールの1つです。これにより、ユーザーは1つ以上のXcodeプロジェクトの継続的インテグレーションをセットアップできます。選択したコンピューターにプロジェクトのビルドに必要なバージョンのXcodeがインストールされている限り、統合はローカル環境またはリモート環境のいずれかで実行できます。

継続的インテグレーションとは何ですか？

継続的インテグレーションとは、開発中のプロジェクトの同じ環境で、自動化された事前に決定されたタスクを実行することです。開発者によって導入されたすべての変更は、同じ環境内で同じ状況下で評価されるため、継続的な検証が可能になります。

Appleは継続的インテグレーションのためにどのような組み込みツールを提供していますか？

すべてのXcodeに付属しているツールには、Application Loader、agvtool、PlistBuddy、xcodebuild、codesignなどがあります。これらのツールは継続的インテグレーションのために特別に作成されたものではなく、スタンドアロンツールとして役立ちます。ただし、継続的インテグレーションのセットアップに追加の機能と汎用性を提供します。

プロジェクトの継続的インテグレーションを設定するために、他にどのようなツールを使用できますか？

Fastlaneは、おそらく現時点で利用可能な最も堅牢なCIツールです。 Bluepillは、複数のシミュレーターを使用してiOSテストを並行して実行するためのツールです。 BuddyBuildは、ここで説明したすべての機能とその他多くの機能を提供するオンライン（クラウド）継続的インテグレーションサービスです。