iOSプロジェクト用GitLab CI設定 | about.gitlab.com

法律: IT 解説記事 GitLab CI アプリ iOS フノス(訳者)

  iOSプロジェクト用のGitLab CIの作り方を、頭から尻尾まで、懇切丁寧に教えます。
 

  だからって、なんでCIなの?

  継続的インテグレーション (CI)は、じつは偉大なツールなんです。
 きちんと使いこなせれば、もっと正しく、もっと生産的に、もっと質の高いコードを書きたいという、エンジニアの欲求に素直に応えてくれます。
 「テストに合格したアプリケーションしか、コミットさせない」
 「コードベースへの変更をすぐにわかるようにしたい」
 「開発をもっと速く簡単にしたい」
 これらの要望がころっと叶ってしまうツールが、まさしく「CI」なんですよ。

 

  GitLab では全てのプロジェクトにおいて、無料かつ自由なCIのビルドインを認めております。

  この記事ではそのGitLab CIの設定法から、ワークフロー、利点・欠点を含めたCIの性質までを取り上げます。

 それではまず最初に、Xcodeプロジェクトでできる大まかな操作を説明いたします。

  1. コードベースをコピーして変更を加えて、GitLabへのコミットをプッシュすること。
  2. コードベースに変更があったことを検知すること。
  3. Macプロジェクト用に設定したGitLab ランナーで、ビルドを実行すること。
  4. ランナーの動作は「.gitlab-ci.yml」というファイルに記述する。これにはビルド工程とテスト工程の両方を指定できる。
  5. GitLabランナーから出された報告は、GitLabへ届けられるようになっている。
  6. GitLabはビルドの結果を表示すること。


 この記事は、 Jeremy White氏のブログ記事を加筆修正したものです。これから紹介する方法には、開発環境や細かい手順などに差異があります。


 

  前提条件と開発環境

  この記事ではiOSプロジェクトを制作することを念頭に、GitLab CIの設定法を最初から最後まで説明いたします。

 設定に取り掛かる前に、皆さんに守っていただきたい条件があります。

   GitLab's strategy documentという、このシステムの開発方針を記した文章があります。それによると、「誰でも開発に携われること」を方針の1つにしているそうです。
 そして、この記事はGitLabを使いたいという、初心者から上級者まで全てのレベルの開発者さんに向けて書いています。なので、XcodeでGitLabプロジェクトを制作するための基礎知識から説明している場面もあります。
 ターミナルや、gitの使い方の解説がそれです。
 少々長い文章になるかもしれませんが、その辺はご了承ください。
 

  今回の記事では、次の開発環境を使いました。


 そして、新しいGitLabプロジェクトは既に作成されていることを前提に考えています。
 この解説をそのまま実行したいという方は、大体同じ道具をそろえて、GitLabプロジェクトは作成しておいてくださいね。

 

  Xcodeプロジェクトの設定

  あくまで例示としてですが、今回はsingle-view iOSプロジェクトをXcodeで制作することにしました。
 (写真1)新しいプロジェクト

  せっかくプロジェクトを作るのですから、Unit TestsとUI Testsは実施したい。なので、プロジェクトのオプションでその2つの項目に許可を与えます。
  すると、Xcodeが「テンプレートテストクラス」というテストユニットを作成するはずです。あとでこれをGitLab CIのテストツールとして使っていきましょう。
 一番上の欄に「Product Name」とありますね。ここにプロジェクトの名前を入れることを忘れないでください。
 必要事項を記入して、Nextボタンをクリックします。
 (写真2)テストを許可する
 

  iOSプロジェクトの置き場所を指定します。これはお好みで構いませんが、ご自分のMacの中にgitレポジトリを作成することもできます。
 (写真3)Macの中にgitレポジトリを作成

  Xcodeプロジェクトが作成されましたね。次は、そのプロジェクトを開いて、スキームの共有をする必要があります。
 Appleの説明書に、こんな一言が書いてあります。

  スキームは「ビルドのターゲットをどれにするか」「ビルドには具体的に何を使うか」「ターゲットが出来上がったら、どの環境で実行させるか」などの設定を集めたものです。

  このようなことから、スキームの共有をすることで、GitLab CIがテストやビルドの時に、どのようなものが必要かを読み取ることができるようになるのです。

  Xcodeのスキーム(scheme)を共有するには、「Product > Scheme > Manage Schemes」を選択してください。
 (写真4)Manage Schemesの画面
 

  チェックボタンを押したら、その下の「Close」ボタンを押します。

  このXcodeプロジェクトには既に2つのテスト用ファイル(ユニットテスト、UIテスト)が用意されているはずです。
 テストを実行するために、あらかじめSimilatorデバイスをプロジェクトにインストールしておきます。「Product > Test」に移動して、プロジェクトをビルド、そしてSimilatorに立ち上げます。すると、テストツールが起動するしかけです。

 試験結果は、Xcodeの中で確認することができます。
 (写真5)試験結果が表示されたXcode
 

  小さくて見えづらいかもしれませんが、緑色ののチェックマークが、検定関数(左側の欄)の隣に表示されています。また、ファイルの中にも同様のチェックマークがついていますね。テストが成功した証です。
 ここで何も問題がなかったのなら、Xcodeプロジェクトは一旦閉じてしまってもよいでしょう。

 

  次の工程に移ります。ターミナルを開きましょう。そこから先ほど作成したiOSプロジェクトがあるフォルダに移動します。 

  そこに「.gitignore」ファイルを追加すると、何かと便利です。
  Swiftプロジェクトでは、次のコマンドで指示します。

======================
$ curl -o .gitignore https://www.gitignore.io/api/swift
======================

 これがObjective-Cプロジェクトになると少し違うので、ご注意ください。

======================
$ curl -o .gitignore https://www.gitignore.io/api/objective-c
======================
 「curl」コマンドは特定のページからコンテンツをダウンロードしてくるときに使います。
 今回はここに「gitignore.io」のURLを指定して、レポジトリにgitignoreファイルを作りました。

 

  Xcodeのgitレポジトリを初期化したい場合は、GitLabプロジェクトのオリジナルURLを、以下のコードでセットする必要があります。
 (<username>の部分をあなたのGitLab ユーザー名、<project>をプロジェクト名に置き換えてください)

======================
$ git remote add origin git@gitlab.com:<username>/<project>.git
======================
 あとは、xcprettyをインストールするだけで、Xcodeの設定は完了です。
 xcprettyは、ビルドやテストの結果をさらに読みやすい形式に変換してくれるソフトです。

 

   GitLabランナーのインストールと登録

  これからMacにGitLabランナーをインストールします。
 GitLabランナーとは、ビルドやテストを実行するための装置です。設定には専用のコンフィグファイルを使います。
 GitLabではすでに、OSX向けのランナー・インストール説明書が発表されていますが、今回はプロジェクトの関係上、その内容を少し変更することにしました。(たとえば、runner registerの部分など。)

======================
$ gitlab-ci-multi-runner register
WARNING: Running in user-mode.
WARNING: The user-mode requires you to manually start builds processing:
WARNING: $ gitlab-runner run
WARNING: Use sudo for system-mode:
WARNING: $ sudo gitlab-runner...
====================== 

 ご自分でGitLabサーバーを管理している場合は、コーディネーターURLを入力して、CIをインストールすることができます。

======================
 Please enter the gitlab-ci coordinator URL (e.g. https://gitlab.com/ci):
https://gitlab.com/ci
======================

  GitLabの Project Settingsページで、プロジェクトに使用するCIトークンに使用許可を出しましょう。
 なお、CIトークンはプロジェクトが個別に保有しています。

======================
 Please enter the gitlab-ci token for this runner:
 <CI runner token from Project > Settings > Runner>
======================

 register(認証)の段になったら、あなたが現在使っているMacをランナーに記述したほうがよいでしょう。何か適当な名前を入力してから、「return」を押して登録しなおすこともできます。

======================
Please enter the gitlab-ci description for this runner:
[Your-Mac's-Name.local]:
======================

 ランナーは複数作成する場合があります。それを識別するためのタグを用意しておくとよいでしょう。
 特に、ビルド環境を識別できるような名前をお勧めします。
 たとえば、今回の場合「iOS 9.2」「Xcode 7.2」「OS X 10.11」という環境が支度されていますね。
 それらを「ios_9-2」「xcode_7-2」「osx_10-11」などに置き換えます。
 このほかにも、ビルドのステージごとに分類してみたり、ツールチェーンやプラットフォームなどを基準に名前を付ける方法もあります。
 

======================
 Please enter the gitlab-ci tags for this runner (comma separated):
ios_9-2, xcode_7-2, osx_10-11
======================

 GitLab ランナーの認証が成功すると、ランナーに個別のrunner IDが支給されます。

======================
 Registering runner...     succeeded runner=s8Bgtktb
======================
  そして、ランナーがxcodebuild(ビルド/テスト)を実行する際に、どのような指示形態で動作するかを指定します。
 いくつかの選択肢が提示されていますが、今回は「shell」を選択しました。

======================
Please enter the executor: virtualbox, ssh, shell, parallels, docker, docker-ssh:
shell
Runner registered successfully. Feel free to start it, but if it's running
already the config should be automatically reloaded!
====================== 
 画面に出された指示に従って(installstart)操作すれば、ランナーのインストールが完了するはずです。
 

  Project Settingsに移動して、ランナーがきちんと認識されているかを確かめてみましょう。

  (写真6)このように表示されていれば、登録したランナーは使用可能です!

 

  今度はコマンドからも確かめてみますよ。

======================
$ gitlab-ci-multi-runner verify
WARNING: Running in user-mode.
WARNING: The user-mode requires you to manually start builds processing:
WARNING: $ gitlab-runner run
WARNING: Use sudo for system-mode:
WARNING: $ sudo gitlab-runner...

Veryfing runner... is alive   runner=25c780b3
======================
 同じIDが表示されましたか?(ここでは、「25c780b3」とされています)
 

  ランナーの登録が終了しました。
 そしたら、ビルドとテストの内容を具体的に指定しましょう。
 テキストエディターを開いて、「.gitlab-ci.yml」を次のように編集します。

============================================
stages:
  - build

build_project:
  stage: build
  script:
   - xcodebuild clean -project ProjectName.xcodeproj -scheme SchemeName | xcpretty
   - xcodebuild test -project ProjectName.xcodeproj -scheme SchemeName -destination 'platform=iOS Simulator,name=iPhone 6s,OS=9.2' | xcpretty -s
  tags:
   - ios_9-2
   - xcode_7-2
   - osx_10-11
============================================

  追記:作成した「.gitlab-ci.yml」ファイルは、iOSプロジェクト(ProjectName.xcodeproj)の中に配置してください。
 これを教えてくれたPaloさん、ご指摘ありがとうございます。
 

  設定ファイルの内容



 変更可能なポイント


 「.gitlab-ci.yml」ファイルの編集が終わったら、GitLabの左側にスライドバーがありますね。そこの「Build」タブに移動して、右上にある「CI Lint」というボタンをクリックし、CIを正しい形式にまとめ上げてください。
 (写真7)「CI Lint」ボタンの位置

  テキストボックスの中に「.gitlab-ci.yml」ファイルのコンテンツをペーストして、「Validate」をクリックします。
 次のように出たら、そのファイルはプロジェクトで使用可能です。

======================
 Status: syntax is correct
======================

  ただし、このツールでは「.gitlab-ci.yml」ファイルに大きな矛盾がないかどうかを判定することしかでません。
 果たして外部ツールであるSimulatorに、正しいものが設定されているかどうかなどは、きちんと人の目で確かめるしかありません。

  なお、「.gitlab-ci.yml」にはまだまだ沢山のカスタマイズ方法があります。
 1つのjobが成功したか失敗したかで、次のjobを決めるようにしたり、
 ブランチへのコミットがあったら作動するjobとか、
 tagが追加されたときにだけ作動するjobなどを決めることもできます。

 詳しいオプションは、こちらのドキュメントで解説されています。ぜひ、GitLab CIを柔軟にパワフルにカスタマイズしてください。
  (訳者より一言:iOSに当てはまるかどうかはわかりませんが、他の方々の設定を見ている限り、「before_script」と「cache」の最適化に注力している気がします。
  あとね、「android用プロジェクトの設定」で、「常に最新パッケージにしておいてほしいソフトは全部before_scriptに書いといた方がよい」という主張があったとおもうよ。)


 

  ビルドにかかる前に

  さて、早速ビルドに取り掛かりたいところですが、まだ設定は終わっていませんよ。

 新しいプロジェクトでは、デフォルトでCIの使用許可が出されています。
 しかし、そのままの状態ではGitLab上でビルドの状態が公開されてしまいます。
 iOSプロジェクトの場合、環境変数などを外部に公開したくないことがほとんどかと思われます。
 なので、Project Settingsから、「Public builds」に許可を出さないように設定してください。この設定にすることで、開発メンバー以外はビルドの結果を見られないようになります。
 

  この場合ですが、ランナーの共有もブロックした方が得策かと思われます。Project Settingsから「Disable shared runners」をクリックしてください。

 やはりプロプライエタリなアプリを制作する場合には、プロジェクト専用のランナーを使用するように心がけましょう。

 

  さあ、これでようやくCIビルドの準備が整いました!

 

  プロジェクトをビルドする

  必要な設定は、すべて前の段階で終えてますからね。GitLabにプロジェクトをプッシュするだけでビルドが始まります。

 ターミナルから次のコマンドを打ってください。

======================
$ git add .
$ git commit -m "First commit."
[...commit info...]
$ git push origin master
[...push info...]
======================
 あとは、GitLabランナーに施した設定どおりに、Simulatorでアプリの検査が行われるはずです。
 ここでホームスクリーンに移動しましょう。
 

  そこから「Builds」ページに移動します。そこに検査結果が表示されているはずです。

  (写真8)「Builds」ページ

 緑色のチェックマークがついていたら、ビルド成功です。
 チェックマークをクリックすると、ビルドの状態を確認することができます。
 (写真9)ビルドの状態
 

  ここに、「.gitlab-ci.yml」ファイルの設定に即した結果が表示されるはずです。
 このログの一番下には、次のような文章が表示されます。

============================================
All tests
Test Suite GitLab-CI-for-iOSTests.xctest started
GitLab_CI_for_iOSTests
   . testExample (0.001 seconds)
   T testPerformanceExample measured (0.000 seconds)
   . testPerformanceExample (0.324 seconds)


Executed 2 tests, with 0 failures (0 unexpected) in 0.325 (0.328) seconds

All tests
Test Suite GitLab-CI-for-iOSUITests.xctest started
 GitLab_CI_for_iOSUITests
   . testExample (3.587 seconds)


Executed 1 test, with 0 failures (0 unexpected) in 3.587 (3.589) seconds


Build succeeded.
============================================
 ここでビルドが失敗した場合は、アプリケーションに手直しを入れた方がよいでしょう。

 

  MacでGitLab ランナーを操作する

  GitLab Runnerには専用のコマンドとオプションがあります。

============================================
$ gitlab-ci-multi-runner --help
NAME:
  gitlab-ci-multi-runner - a GitLab Runner

USAGE:
  gitlab-ci-multi-runner [global options] command [command options] [arguments...]

VERSION:
  1.0.4 (014aa8c)

AUTHOR(S):
  Kamil Trzciński <ayufan@ayufan.eu>
COMMANDS:
  archive   find and archive files (internal) アーカイブファイルを探す
  artifacts   upload build artifacts (internal) ビルドアーティファクツをアップロードする
  extract   extract files from an archive (internal) アーカイブからファイルを絞り込む
  exec   execute a build locally ローカルでビルドする
  list    List all configured runners ランナーの設定を全て表示する
  run   run multi runner service 複数のランナーを起動する
  register   register a new runner 新たなランナーを登録する
  install   install service  サービスをインストールする
  uninstall uninstall service サービスをアンインストールする
  start   start service サービスを開始する
  stop   stop service サービスを停止する
  restart   restart service サービスを再起動する
  status   get status of a service サービスの状態を見る
  run-single   start single runner ランナーを単品で動かす
  unregister   unregister specific runner ランナーの登録を取り消す
  verify   verify all registered runners 全ての認証済みランナーを確認する
  help, h   Shows a list of commands or help for one command コマンドの使い方を表示する

GLOBAL OPTIONS:
  --debug   debug mode [$DEBUG]
  --log-level, -l "info"   Log level (options: debug, info, warn, error, fatal, panic)
  --help, -h   show help
  --version,   -v print the version

============================================


  コミットをプッシュしても、すぐにはランナーを作動させたくない時があるかもしれません。
 そんな時には、ランナーをストップさせる操作を執り行うとよいでしょう。
======================
$ gitlab-ci-multi-runner stop
$ gitlab-ci-multi-runner status
gitlab-runner: Service is not running.
======================

 この場合、プッシュはされていても、ビルドは未完成ということで表示されます。そして、ランナーを手動で開始させるとビルドが始まることになっています。

======================
$ gitlab-ci-multi-runner start
$ gitlab-ci-multi-runner status
gitlab-runner: Service is running!
======================
 あとは、コンフィグ通りのビルドがされるはずです。

 

  番外編:アーカイブの保存を自動化したい

  masterブランチにコミットがあったときにのみ、アプリケーションのアーカイブを作成して、GitLab上にアップロードする設定をご紹介します。

 

  さきほどの「.gitlab-ci.yml」ファイルを開いて、「archive_project」jobを追加します。

============================================
stages:
  - build
  - archive

build_project:
  stage: build
  script:
   - xcodebuild clean -project ProjectName.xcodeproj -scheme SchemeName | xcpretty
   - xcodebuild test -project ProjectName.xcodeproj -scheme SchemeName -destination 'platform=iOS Simulator,name=iPhone 6s,OS=9.2' | xcpretty -s
  tags:
   - ios_9-2
   - xcode_7-2
   - osx_10-11

archive_project:
  stage: archive
  script:
   - xcodebuild clean archive -archivePath build/ProjectName -scheme SchemeName
   - xcodebuild -exportArchive -exportFormat ipa -archivePath "build/ProjectName.xcarchive" -exportPath "build/ProjectName.ipa" -exportProvisioningProfile "ProvisioningProfileName"
  only:
   - master
  artifacts:
   paths:
   - build/ProjectName.ipa
  tags:
   - ios_9-2
   - xcode_7-2
   - osx_10-11
============================================
 「archive_project」jobの内容

  そして、「ProvisioningProfileName」は適切な名前に変更してくださいね。

 developer keysをlogin Keychainの中に入れていると、「archive_project」jobが作動しない場合があります。
 CIにキーチェインを解除するスクリプトは存在しません。自動的にキーを解除する設定をすることはできません。
 なので、ご自分のパスワードは「System Keychain」に移し替えてしまう(ドラッグ&ドロップで)ことをお勧めします。これにより、「login Keychain」が空になって、スクリプトが動作できるようになります。
 

  さっそく、masterブランチにコミットしてみました。
 「build」ページからビルドの結果をご覧いただけるほか、ビルドしたアプリ(アーティファクツ)をダウンロードすることも可能です。
 (写真10)ここからアプリをダウンロード

 

  備考



 筆者について

  Angelo Stavrow

 カナダ・モントリオール在住の品質管理技術者、ソフトウェア開発者。
 オープンソースプロジェクトで主に活動し、ソフトウェアで何か気の利いたものを作ること、息の合ったチームを作ることを第一に活動してる。
 

 

 

 

 

 2017-11-04 19:08:26 / Hnoss
原文サイトを表示
[ 原文 ] https://about.gitlab.com/2016/03/10/setting-up-gitlab-ci-for-ios-projects/
Creative Commons License この作品は、クリエイティブ・コモンズ・ライセンスの下でライセンスされています。
クリエイティブ・コモンズ・ライセンス