比較的大規模な開発者チームによるUnityの新しいプロジェクトへの移行に伴い、テスト用のアプリケーションの自動アセンブリとデバイスへの配信が急増しました。 これは私がプロジェクトに来たときの状況でした（iOS用）：

1. 別のmac-machineで、プロジェクトはリポジトリ（Asset Sever）から手動でダウンロードされました。
2. 手動（ ファイル->ビルド設定->ビルドと実行 ）で、アセンブリがxCodeプロジェクトに起動されました。
3. さらに、xCodeでアーカイブ（ Archive ）が作成されました。
4. アーカイブはipaファイルにエクスポートされ、TestFlightに手動でアップロードされました。
5. さらに、既にTestFlightで必要なテスターに​​アクセスが提供されました。

上記のすべては、いわゆる継続的インテグレーション（Eng。Continuous Integration 、 CI ）を使用して自動化されます。 私の以前のプロジェクトでは、JetBrains（便利なResharperコードリファクタリングツールの作成者）のTeamCityがこれらの目的に使用されていました。 TeamCity （TC）は、継続的インテグレーションシステムに設定された目標を100％満たす非常に強力なソフトウェア製品です。 彼はもっとできる。 しかし、記事のスピーチは彼に関するものではなく（ 彼に関する記事は既にあります）、特にUnityエンジンの開発者向けの新しいUnity Cloud Buildサービスに関するものです。



UPD UnityがUnity Cloud Buildをリリースし、記事を更新しました:)以下の変更と革新について読んでください。



開始するには、以下のリンクの一部にUnity Cloud Build、そのフォーラム、およびドキュメントへのアクセスが必要であることを警告します。

問題

大規模なプロジェクトがあり、上記の手順全体に30分以上かかりました。 アセンブリが作成されたMacは低速でした。 プログラマーがアプリケーションをデバイスにインストールすることはめったにありません（主にエディターですべてがチェックされました）。 したがって、通常、1つのアプローチでは十分ではありませんでした。 デバイスにダウンロードした後、アプリケーションは突然（平均の法則に従って）エラーを検出しました。 さらに、通常のQAはありませんでした。 さらに、これはすべて金曜日の夜に行われました-つまり 私たちはそのような重要な問題のためにすべての不利な条件を取得します:)



これがもはや継続できなかったことは明らかです。 ソリューションはもちろん複雑である必要があり、その一部として、CIを開発に導入するというタスクを設定しました。 タスクは次のように設定されました。

• CIシステムは、可能であれば無料である必要があります。
• Unityプロジェクトのアセンブリをサポートする必要があります。
• そのセットアップは非常にシンプルでなければなりません。
• すべてについてのすべてのために-1営業日以内。

TeamCityでの前回は、最初のビルドをセットアップするために約1日を殺しましたが、その後、これらのビルドを長期間調整および保守しました。 さらに、サーバーへの展開、構成、およびサポートが必要です。 そして今回、Unity Cloud Buildを試してみることにしました。 最近、私は彼について多くのことを聞きました。最初に購入したのは、アセンブリ用のマシンとして独自のサーバーとMacを用意する必要はなく、すべてが彼らの側で行われることです。

UnityはTsugiプラットフォームを取得し、それに基づいてUnity Cloud Buildを構築しました。 サービスはすでにパブリックドメインにあり、Unity開発者は誰でも、無料版の所有者でも、デフォルトで無料プランでシステムを登録して使用できます。 私は彼らのページでUCBに登録し、最初のビルドのセットアップを開始しました。

カスタマイズ

セットアップには約15分かかりましたが、インタラクティブで、いくつかの段階を経ています。

• リポジトリ内のプロジェクトへのリンクを入力します 。 svn 、 perforce 、およびgitでサポートされています。 リポジトリのタイプは、参照によって自動的に決定されます。 UCBはAsset Serverをサポートしていないことが判明しました。これは奇妙なことです-独自のバージョン管理システムをサポートしていません。 私がプロジェクトに取り組むようになったとき、それはちょうどASでした。 ASに会ったとき、最初に私を殺したのは、ブランチ（大規模なプロジェクトにとって重要）のサポートがなく、それらの合併は変更ではなく時間ベースの変更に基づいていることでした。 UCBに対するASサポートの欠如は、プロジェクトをgitリポジトリに移動するもう1つの理由です。
• リポジトリーへのアクセスの構成 。 gitの場合、 UCBは、たとえばbitbucketまたはgithubのプロジェクトの管理パネルで登録する必要があるSSHキーを生成します。 アクセスを取得した後、UCBを使用すると、プロジェクトをアセンブルするブランチを選択できます。
• プロジェクトのセットアップ 。 この段階で、Unityのバージョンを選択することができます。これにより、プロジェクトのアセンブルが行われます。 UCBには、Unity 5 ベータまでのすべてのバージョンが含まれています。 現時点では、UCBはWeb 、 iOS 、およびAndroidプラットフォームをサポートしていますが 、それらにアクセスするには、少なくとも現時点ではiOSおよびAndroidプラットフォームのプロライセンスは必要ありません。）将来、 スタンドアロン プラットフォームとWindows Phoneを追加する予定です。 リポジトリ内の特定のフォルダーをUnityプロジェクトのフォルダーとして指定することもできます。
• アプリケーションのビルドとサブスクリプションを構成します 。 この段階で、アプリケーションをp12形式でサブスクライブするための証明書が表示されます。 iOSの場合、 プロビジョニングプロファイルも示され、xCodeバージョン-5または6（現在6.0.1を使用）を選択できます。

その後、システムは自動的にプロジェクトの構築を開始します。 プロセスの最後に、コンパクトで詳細なビルドログ 、アプリケーション自体+パックされたdSYM （iOS用）が利用可能になります。

UPD 判明したように、Androidの場合、UCBはapkを拡張ファイルに分割できません。 そのため、この場合、テストにのみUCBを使用し、リリースビルドを手動でビルドできます。

コンパイルされたアプリケーションを配布する

UCBでアセンブリを「共有」する方法はいくつかあります。

• 共同研究者 これは、プロジェクトにアクセスできる全員のリストです。 アセンブリの最後に、このリストのそれぞれが、インストールするリンクを含むメッセージをメールで受け取ります。 デバイスでそれを通過し、ワンタッチでアプリケーションをインストールできます。 また、コンピューターのブラウザーから管理パネルに移動してipa-ファイルをダウンロードし、好きなことを行うことができます。 この方法には1つの欠点があります-このリストからすべてがビルド設定とすべてのアセンブルされたアプリケーションにアクセスできます。
• リンク経由で共有します。 特定のアセンブリをダウンロードできるリンクが生成されます。 このリンクでは、誰でもアプリケーションをダウンロード/インストールできます。 それは永続的です、つまり 特定のアセンブリの経時変化はありません。
• UPD TestFlightオプションへのプッシュはなくなりました。 Appleは（テスト用のAndroidアプリケーションのダウンロードを禁止する前に）古い形式でTestflightを閉じ、iTunes Connectを通じてテスト済みアプリケーションを配布するバージョンを提案しました。 Appleの新しい方法の厄介な点は、外部テスト（ 外部テスター 、最大1000テスター）の申請を提出するために、内部テスト-Beta App Reviewに合格する必要があることです。 どれくらいの期間続くかはまだわかりません。まだ試していませんが、アプリケーションはAppStoreに送信する前と同じ基準をすべて満たしている必要があります。 内部テスト（ Internal Testers 、25以下）の場合、テスターはテクニカルまたは管理者の役割でiTunes Connectにアクセスできる必要があり、これは常に可能とは限りません。

その他の機能

• アセンブリの数は無制限です。 たとえば、無料のTCでは、エージェントの数（アセンブリのためにマシンを呼び出すため）とアセンブリの数に制限があります。 追加するには、追加のライセンスを購入する必要があります。
• Unity Cloud Buildマニフェスト 。 デバッグアセンブリに、アプリケーションでアプリケーションがビルドされたコミットに関する情報を表示する機能をビルドしようとしたときに、 アセンブリマニフェストについて学びました。 これはテスト時に非常に便利です。 UCBのメンバーがプロジェクトにJSON形式の「マニフェスト」を埋め込み、テスト、コミット、ブランチ名、ビルド番号などから多くの有用な情報を取得できることがわかりました。しかし、ストア用のアプリケーションをビルドする必要がある場合、このマニフェストはなくなりますそれと一緒に販売:(

詳細設定

設定には[詳細設定]セクションがあります。 より最近では、要求に応じて、テストモードでのみ使用できました。 有料サブスクリプションの所有者が利用できるようになりました。

• 開発ビルド 。 BuildOptions.Development + BuildOptions.AllowDebuggingビルドオプション、およびFile-> Build Settingsの対応する設定に対応しているため、アセンブルされたアプリケーションをデバッグできます。 デフォルトでは、リリースが行われます。
• エクスポート前/エクスポート後のメソッド名 。 これらのメソッドは、プロジェクトをビルドする前とxCodeプロジェクトを作成した後にそれぞれ呼び出されます。 ここで、彼らはすでにあなたに奇跡を起こすことを許しています！ これらのメソッドのクラスファイルは、 エディターフォルダーにある必要があります（必ずしもプロジェクトのルートにある必要はありません）。 これはヘルプには示されておらず、動作するアセンブリを達成するまで時間がかかりました。
• スクリプト定義シンボルは非常に便利なものです。 プロジェクト設定では設定できませんが、アセンブリごとに個別に設定できます。 たとえば、コードではDEBUG 、 RELEASE 、 STOREなどのプリプロセッサ文字を使用します。
• シーンリスト -アセンブリのシーンのリストを個別に指定できます。 たとえば、テスト用の特別なテストシーンがある場合に便利です。

サブスクリプションと価格

Unity Cloud Buildのリリースにより、 サブスクリプションが導入されました。 サブスクリプションには4つのタイプがあり、それぞれ新しいサブスクリプションには前のサブスクリプションが含まれます。

1. 無料 。

• 名前が示すように、これは無料のプランです。
• プロジェクトには1Gbが割り当てられますが、アセンブリ中にプロジェクトフォルダが占有するすべてのスペースが考慮されます。
• ビルド間で少なくとも60分、つまり 次のアセンブリ（自動または手動開始）の前に、少なくとも1時間待つ必要があります。 ただし、 ライブラリキャッシュはデフォルトで有効になっています。
• 一度に1つのプロジェクトのみを収集する機能。
• 他の人をプロジェクトに追加することはできません（ Collaborators ）。 ただし、アセンブリによって生成されたリンクを使用してアセンブリを共有できます（ リンク経由で共有 ）。
• 詳細設定は使用できません。

2. プロ 。

• 月額25ドル。
• プロジェクトごとに2Gb。
• ビルド間で少なくとも30分。
• 一度に最大3つのプロジェクトを収集できます。
• プロジェクトには最大5人を追加できます。
• さらに、 開発ビルドとカスタムスクリプト定義オプションが利用可能です。

3. スタジオ 。

• 月額100ドル。
• プロジェクトごとに5Gb。
• ビルド間の最小5分。
• 一度に最大6つのプロジェクトを収集できます。
• プロジェクトには最大20人を追加できます。
• 追加のオプションは、 エクスポート前/エクスポート後の方法とカスタムシーンリストに使用できます。
• PERFORCEサポート。

4. エンタープライズ 。

• 別のプラン。 価格を交渉する必要があります。
• プロジェクトを組み立てるための別のマシンが際立っています。
• 理論上-プロジェクトをビルドする最速の時間。
• 上記の制限はすべて削除されます。

欠陥または他に何が欲しいですか

• このプロジェクトは比較的長い間進行中です。 これは無料のサブスクリプションを意味します。 また、ビルド間に1時間の制限があります。 現在、ローカルで5〜10分で組み立てられているプロジェクトは、15〜50分でUCBに送られます。 その理由は、UCBが自宅での保管を許可しておらず、毎回リポジトリから再ロードされるためです。 存在する唯一の最適化は、[ ライブラリディレクトリのキャッシュ ]オプションです。プロジェクトのライブラリフォルダーをキャッシュできるため、再度ビルドするときにすべてをエクスポートする必要がありません。 一般に、プログラマーがテストのためにプロジェクトをローカルでビルドする機会がある場合、この時間は開発にとってそれほど重要ではありません。 有料プランでは、アセンブリ間の時間が短縮されます。最も高価なものには、 専用のビルドマシンがあり、企業に個々のマシンを割り当て、これらのマシンにプロジェクト全体をキャッシュすることにより、非常に高速なアセンブリを約束します。 誰かが試してみた場合、そうでない場合はコメント欄で退会してください。
• feature / *などのブランチファミリからアセンブリを構成する方法はありません 。 TCにはこのような可能性があり、UCBは常に厳密に指定されたブランチから収集します。 git-flowパラダイムに精通している人は、プログラマがタスクの異なるブランチを開始し、（彼らまたはテスター）がアセンブルされたアプリケーションですぐにテストできる場合、開発に非常に役立ちます。 その結果、さまざまなブランチ用に構成されたUCBのいくつかのプロジェクトで管理しました。たとえば、 マスター （テストとストアへのアップロード用に個別にリリースアセンブリ）、 開発 、現在のリリースと現在の機能の特定のブランチ（ フィーチャー ）の継続的なテストのためのリリースからのブランチです。 当然、これらのプロジェクトには、 Development Build 、 Scripting Define Symbolsなどの異なる設定があります。 したがって、テスト用のリリースアセンブリとAppStoreは、 リリースライトがマスターにマージされるとすぐに自動的に収集されます（ git-flowに従って）。
• プロセスに自動テストを含める方法はありませんが 、ミンスクの最後のDevGammでDmytro Mindraはそのような機会があったと誓いましたが）当然、これはUnity Test ToolsとPre-Export Methodオプションを介して手動で行うことができますが、より深刻なネイティブサポートが必要です、テスト結果とグラフの表を含む）
• ローカルマシンでアセンブルされるプロジェクトがUCBでアセンブルされるものに対応するとは限らず、そのようなアプリケーションはデバイスで常に機能するとは限りません。 たとえば、Soomlaからのゲーム内購入にプラグインを使用しました。 ローカルでビルドされたアプリケーションは正常に機能しましたが、UCBでビルドされたアプリケーションはプラグインの初期化関数でハングしました。 その結果、SoomlaはBuild Settings> Other Linker Flagsに `-ObjC`フラグを追加し、 UCBによって誤って使用されることが判明しました。 この問題はすでに修正されていますが、そのため、しばらくの間、UCBからビルドをテストできなかったため、古い方法でプロジェクトをローカルにアセンブルする必要がありました。
• UPD 分割アプリケーションバイナリはサポートされていません。 Google Playのアドオンファイルを受け取るためにプロジェクト設定でアプリケーションバイナリの分割がオンになっている場合、アプリケーションが50Mbを超える場合、それを無効にする必要があります。そうしないと、アドオンファイルなしでUCBで出力が動作しなくなります。 アドオンのサポートは実装されていませんが。

まとめ

だから、Unity Cloud Buildが好きでした。 プロジェクトは開発中であり、フォーラムは開発者の現在の要求について尋ねており、徐々にそれらを認識しています。テクニカルサポートは非​​常に迅速に対応します。 Unityでプロジェクトを開発し、CIについて考えている場合は、Unity Cloud Buildを試すことをお勧めします。 時間とお金を節約します。



長所：

• クイックセットアップ。 既製の証明書、プロファイル、リポジトリへのリンクがあれば、わずか2分で完了します。
• AndroidとiOSの「無料」で収集する機能、ライセンスは必要ありません。Macも必要ありません。
• ビルド時間を気にしない人にとって、これはアプリケーションのすべてのビルドを自動的にビルドして保存する絶好の機会です。
• アセンブリをカスタマイズするための追加機能。
• プロジェクトとアセンブリの数は無制限です。

短所：

• 無料プランでのビルド時間が比較的長い。 最も高価な計画では、彼らは迅速な組み立てを約束しますが、私はそれを自分で試したことはありません、私はそれを保証することはできません。
• Hg、TFS、Asset Serverはサポートされていません（ただし、最後の2つを使用することはお勧めしません）。
• 自動テストの組み込みサポートはありません。

コメントで質問、提案、説明を待っています！



おそらく誰かが私の以前の記事を読むことに興味があるでしょう：

• 二日間でゲーム
• Unity3dの2d
• Unity3dのモバイルデバイス用の2Dアプリケーションの最適化

開発を頑張ってください！