pkgファイルをiTunes Connectにアップロードするところまでをコマンドラインから実行できるようになったら、一度流れを整理しておこう。
ビルドからアップロードまでの流れ
- xcodebuildを使って、xcarchiveを作る
- xcarchiveからpkgを出力するためのオプションを書いたplistを用意する
- xcodebuildを使って、xcarchiveからpkgファイルを作る
- deliverを使うための設定ファイル(Deliverfile)を用意する
- deliverを使ってpkgファイルをiTunes Connectにアップロードする
このうち、pkgの出力オプションのplistとDeliverfileは毎回生成する必要がないため、一度生成したら次回以降のフローではそのファイルを使い回していけば良い。
plistファイルについては、基本的に機密情報を含まないため、プロジェクトのレポジトリに保存して、他のチームメンバーが参照できたとしても問題ないだろう。
一方、Deliverfileについては、Apple IDが記載されているので、他のチームメンバーに参照されたくない場合はレポジトリに保存しない方が良いかもしれない。特に、オープンソースの場合などは含めず、レポジトリ外に保存しておいて実行時にプロジェクトのディレクトリーにコピーする形にするのが良いかもしれない。なお、DeliverfileにはApple IDのパスワードは含まれていない。パスワードはKeychainに保存されているため、別のマシンにDeliverfileだけをコピーしてもそのまま実行することはできないので注意。
この一連の流れを改めてコマンドで実行してみる。
cp ~/path/to/Deliverfile . xcodebuild -workspace image-concat.xcworkspace/ -scheme Tunacan clean archive -archivePath build/archive.xcarchive | xcpretty xcodebuild -exportArchive -archivePath build/archive.xcarchive/ -exportPath build/pkg -exportOptionsPlist export-options.plist | xcpretty deliver --pkg build/pkg/Tunacan.pkg
チェックアウトするところからスクリプト化する
開発・デバッグに使っているディレクトリのファイルを使って申請用のビルドを作るよりは、クリーンな状態でレポジトリからプロジェクトをクローンしてきて、そこでビルドを作る形で運用する方が望ましい。作業中のディレクトリには、コミットしていないファイルが存在しうるため、次回他の環境で、あるいは他のメンバーがビルドをしようとした時に違う結果になってしまうリスクがあるからだ。
mkdir app_submission cd app_submission git clone プロジェクトのgitのパス project cd project pod install #CocoaPodsを使っている場合のみ cp ~/path/to/Deliverfile . #Deliverファイルをコピーする xcodebuild -workspace image-concat.xcworkspace/ -scheme Tunacan clean archive -archivePath build/archive.xcarchive | xcpretty xcodebuild -exportArchive -archivePath build/archive.xcarchive/ -exportPath build/pkg -exportOptionsPlist export-options.plist | xcpretty deliver --pkg build/pkg/Tunacan.pkg cd ../../ rm -rf app_submission
ここではわかりやすくするために、チェックインしたディレクトリの下のbuildディレクトリにxcarchve, pkgを出力しているが、後で出力内容を確認したい場合は、チェックアウトしたディレクトリとは別のディレクトリ~/Documents/my_app_submissionなどに出力するか、サブミット後にxcarchive, pkgファイルをこれらの場所にコピーするようにすると良い。
ここまで出来ると、いよいよJenkinsやBitriseなど、作業用のマシンと別の環境で申請用のビルドを作ったり、テストを走らせたりすることができるようになる。
