🈹 👨🏿‍⚕️ 👩‍❤️‍💋‍👨 4時間でBuddyBuildからGitLab CIに移行する方法 🎵 🔞 ⛹🏿

背景

1年半前、iOS FunCorpチームは、iOSおよびAndroidプロジェクトのシンプルなCI組織向けの新しいサービスに移行しました。

それ以前は、BambooでCIを使用していましたが、多くの問題があったため、完全に放棄してBuddyBuildに切り替えました。

CIが何であるか、アプリケーションをAppStoreにアップロードする方法を知ることさえできなかったため、コード、テスト、および製品開発を冷静に処理できるほど単純に機能していました。
しかし、時代は変わっており、BudduBuildは同じではないため、別の方法を探し始めました。
この記事では、チームが選択した新しいソリューションについて説明し、独自にCIを整理するためのスクリプトを提供します。

良いという意味

BuddyBuildでは、シンプルさに惹かれました。まず、いくつかの手順を実行する必要があります。

GitHub / GitLab / BitBucket経由でログインします。
プロジェクトでリポジトリを指定します。
サービスにアカウントと配布証明書を与えます。
サービスの側で「魔法が起こる」まで待ちます。

その後すぐに、すべてのブランチでテストとアーティファクトを取得し、明確なUIを使用してアセンブリルールを構成し、Xcodeバージョンをすばやく切り替えて、AppStore / TestFlightでサービスから直接リリースできます。

BuddyBuildの使用を開始したとき、無料で使用できましたが、数か月後に終了しました。現在、スターターパックは月額79ドルです。私たち自身のために、279ドルで3つの競争力のあるビルドのプランを選びました。

BuddyBuildはうまく機能しましたが、長続きしませんでした。

サービスの人気の高まりと、iFunnyのコード量の増加により、ビルド時間はテストおよびアーティファクトのビルドの安定した20分から70分に増加しました。

サービスを使用してキャッシングのソリューションを見つけようとしましたが、単純な設定では価値のあるものは見つかりませんでした。

一方、Appleはこのサービスを購入し、私たちはそれを放棄するという最終決定を下しました。

CI / CDの要件

CIの以前の経験に基づいて、新しいシステムにはいくつかの要件がありました。

エージェントUIへのアクセス数を最小限に抑えて、エージェントとビルド環境を迅速に展開する必要があります。
エージェントUIを入力せずにXcodeを更新し、複数のバージョンを切り替えることができます。
プルリクエストと統合します。
AppStoreでのアセンブリとアンロードには、少なくともサードパーティの依存関係を使用します。
さまざまなブランチのビルド手順をカスタマイズおよびカスタマイズする機能があります。
UIのボタンのみで、成果物のアセンブリを開始します。

Gitlab CI

BuddyBuildを放棄する決定とともに、アイデアはGitHubからGitLabに移行するようになり、既に組み込みのCI / CDシステムがあります。つまり、マージリクエストに必要な統合があります。

エージェントの作業環境を設定する

まず、画面共有を使用してSSH経由でエージェントにアクセスできるようにする必要があります。これは、共有設定で行われます。

これで、CIエージェントに接続するために、ターミナルとSSHクライアントを使用できます。

ssh user@local.ip

SSH経由で正常に接続した後、sudoコマンドのパスワード使用を無効にする必要があります。これは安全ではないように思えるかもしれませんが、私たちと一緒にいるすべてのエージェントはローカルネットワーク内でのみ利用可能であることを考慮して、自動化を改善するためにsudoのパスワードを無効にします。これを行うには：

 sudo visudo

標準のVimエディターが開きます。ここで、行を変更する必要があります。

 %admin ALL = (ALL) ALL

行ごと

 %admin ALL = (ALL) NOPASSWD: ALL

多くのiOS開発者はコンソールを掘り下げることを好みませんが、Vimを使用することはめったにないため、これらの行を変更する方法について段階的な指示を保持してください。

iを押して、挿入モードに入ります。
矢印で目的の行を見つけて変更します。
次へ
入力して：wを保存します。
visudoを終了するには、qを入力します。

まず、各エージェントにHomebrewパッケージマネージャーが必要です。これは、次のコマンドでインストールできます。

 sudo echo | ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

ここではechoコマンドを使用して、インストール確認メッセージが表示されないようにします。
その後、Homebrewから必要な最小限の依存関係を設定できます。選択したものは次のとおりです。

XCPretty これにより、xcodebuild iOSプロジェクトのビルド用の標準コマンドの出力をきれいにフォーマットできます。
```
 sudo gem install xcpretty 
```
fastlane 。プロジェクトのビルドが外部の何かに大きく依存することを望まないため、その機能は最小限に使用します。
```
 sudo gem install fastlane 
```
xcode-install 。このツールを使用すると、AppStoreにアクセスせずにXcodeをインストールし、複数のバージョンを切り替えることができます。
```
 sudo gem install xcode-install 
```
CocoaPods この依存関係マネージャーは、すべてのiOS開発者になじみがあります。
```
 sudo gem install cocoapods 
```

これで、次のコマンドを順番に実行してXcodeをインストールできます。

 export FASTLANE_USER="your@account.todevapple" export FASTLANE_PASSWORD="yourpasswordtoaccont" xcversion install 9.2

エクスポートを実行することはできませんが、インストールプロセス中にApple IDの電子メールとパスワードが要求されます。

これらの簡単な手順を完了すると、エージェントは大部分のiOSプロジェクトを収集する準備が整います。

エージェント登録

エージェントがGitlab CIでプロジェクトを表示するには、プロジェクトをインストールして登録する必要があります。

これは、SSHとエージェントのコマンドラインを使用して行うこともできます。
まず、エージェントをダウンロードしてインストールします。

 curl --output /usr/local/bin/gitlab-runner https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-darwin-amd64

私たちは実行する権利を与えます：

 chmod +x /usr/local/bin/gitlab-runner

gitlab-runnerをサービスとしてインストールして実行します。

 gitlab-runner install gitlab-runner start

次に、CIにランナーを登録する必要があります。これは、次のコマンドで実行されます。

 gitlab-runner register -n --url CI_URL --registration-token TOKEN --tag-list fastlane,cocoapods,osx_10-13,xcode_9-2 --executor shell

これは、詳細に説明する必要があるチームです。
CI_URLとTOKENは、GitLabのプロジェクト設定で取得できます。
設定-> CI / CD->ランナー->特定のランナーを手動でブロック
--tag-list ：タグは、後でプロジェクト自体を設定するときに必要になることを示しています。

たとえば、エージェントにインストールされているXcodeのバージョンや、エージェントで実行する予定のタスクの種類に応じて、変更することもできます。
--executor shell ：エージェントがコマンドラインでアクションを実行する必要があることを示します。

CocoaPodsの問題を回避するには、次のコマンドも実行する必要があります。

 echo 'export LC_ALL="en_US.UTF-8"' >> ~/.bash_profile echo 'export LANG=en_US.UTF-8' >> ~/.bash_profile

これは、炉床の設置時にコーディングエラーが発生しないようにするために必要です。
エージェントが正常に登録されると、設定で確認できます。
設定-> CI / CD->ランナー

プロジェクトのセットアップ

GitLab CIで動作するようにXcodeプロジェクトを構成することは残っています。

これを行うには非常に簡単です。プロジェクトのルートに説明を含む.gitlab-ci.ymlファイルを配置する必要があります。

このファイルがリポジトリに追加されると、CIシステムはそこに指定されたコマンドの実行を開始します。

ymlファイルの例：

 stages: - test - archive before_script: - git submodule init - git submodule update --recursive - pod install --repo-update archive_project: stage: archive script: - fastlane match appstore - xcodebuild -workspace iFunny.xcworkspace -scheme iFunny archive -archivePath build/iFunny.xcarchive | xcpretty only: - master - triggers - web artifacts: paths: - build/iFunny.xcarchive tags: - xcode_9-2 - osx_10-13 - cocoapods - fastlane test_project: stage: test script: - xcodebuild test -workspace iFunny.xcworkspace -scheme iFunny -destination 'platform=iOS Simulator,name=iPhone 7,OS=11.2' | xcpretty tags: - xcode_9-2 - osx_10-13 - cocoapods - fastlane

GitLab CIのyml形式については、こちらで詳しく説明しています。

サンプルファイルを簡単に使用できるように、使用する主なポイントについて説明します。

before_script -CIの各作業の前に完了する必要がある一連の指示を記述します。私たちにとって、これはサブモジュールの更新と炉床のインストールの標準セットです。
archive_project -xcarchiveでアーティファクトを取得するために使用される名前。

スクリプトで、完了する必要があるすべての指示を指定します。

 fastlane match appstore

Fastlaneには、証明書を同期するための適切なmatchコマンドがあります（matchの使用の詳細については、fastlaneのWebサイトを参照してください）。

アーカイブアセンブリを開始するメインコマンド：

 xcodebuild -workspace Project.xcworkspace -scheme ProjectScheme archive -archivePath build/Project.xcarchive | xcpretty

Project.xcworkspace-ワークスペースを含むファイル。
ProjectScheme-メインターゲットを使用したスキーム。
build / Project.xcarchive-作業成果物が収集されるパス。次に、アーティファクトでこのパスを使用します：アーカイブの取得元をCIに指示します。

唯一のブロックで、この作業はmasterブランチでのみ、またはWebから起動するとき、つまりCI / CDのRun Pipelineボタンから起動するときにのみ実行する必要があることを示します。

タグは、この作業を実行できるようにエージェントに登録する必要があるタグです。これで、エージェントの登録時に指定した内容が完全に繰り返されます。
ファイルの次は、 test_projectの操作の説明です。

ここで興味深いのは、テスト実行行です。

 xcodebuild test -workspace Project.xcworkspace -scheme ProjectScheme -destination 'platform=iOS Simulator,name=iPhone 7,OS=11.2' | xcpretty

-destination設定では、エージェントで正確に使用可能なシミュレーターを指定します。

SSHコマンドを使用して、エージェントで使用可能なデバイスのリストを表示できます。

 instruments -s list

.gitlab-ci.ymlファイルを構成したら、それをリポジトリに追加すると、ファイルを含むブランチでテストが自動的に実行されます。

おわりに

GitLabと組み込みCI / CDシステムのセット全体をセットアップするために、約半日を費やしました。これは、BuddyBuildのセットアップに20分以上かかりました。
しかし、私たちが移動から得たもの：

プロジェクトを組み立てるための独自のエージェントとそれらと連携するためのシステム。
テストを使用したアセンブリの時間を70分から6分に短縮したり、テストとアーカイブを使用した完全なアセンブリの時間を最大30分に短縮したりできました。
組立時間を最適化する機会。
カスタマイズやあらゆるサービスとの統合が可能です。

私たちのチームにとって、GitLab CIは一時的なソリューションです。現在、Jenkinsに移行する準備を進めており、プロジェクトにさらに自動化を追加します。

おそらく、この記事で説明した経験により、読者は4時間以内にGitLab CIに切り替えることができます。

また、簡単にするために、記事で説明されているコマンドを使用したスクリプトをいくつか紹介します。

依存関係のインストール。
install_dependencies.sh
エージェントのインストールと登録。
install_agent.sh

4時間でBuddyBuildからGitLab CIに移行する方法

背景