stage一日目担当の@keroxpです。普段は大学の研究室でインターフェースの研究をしていたり、仕事先の会社でiOSアプリの開発を行っていたりします。今回私が取り上げるテーマは「Xcodeと自動化」です。Integration」だったのですが、CIを含めた自動化という題材でお送りしたいと思います。自動化の意義iOSに限らず、ソフトウェア開発の日常には様々なイライラが存在します。じ作業を手動で行わなくてはならなくなります。Yourself!!そこでこの記事ではXcodeを用いたiOSアプリケーションの開発で発生しがちな面倒な人力処理を自動化するためのTipsを実験的にまとめてみます。ビルド設定の自動化XcodeはIDEとしては優れている部類だと思いますが、それはビルドの複雑な処理をうまい具合に隠蔽しているからであって、ビルドのプロセス自体はとても複雑です。Xcodeのビルドオプションは設定項目が多すぎて何がどういうオプションなのかまったく把握できません。初期設定のままなら問題ありませんが、少し手を加えたりすると途端にビルドできなくなったりして困ります。Settingの画面そこでおすすめするのがxcconfigファイルです。Configurationのまとめ設定ファイルで、xcconfigファイルをプロジェクトにaddしておくと、プロジェクトのinfoタブから設定できます。Configurationを分ける必要があるのは主にDebugビルドとReleaseビルドですが、ONLY_ACTIVE_ARCHやCOPY_PHASE_STRP、ARCHSといった闇の深そうな設定をうまくまとめてくれているxcconfigファイルがあります。Spahr-Summers氏が公開しているファイルで、Mantleやoctokitなどのgithub謹製のプロジェクトで用いられている秘伝のconfigファイルです。ありがたく使わせてもらいましょう。Analyzerの設定が入っており、かなりstrictな開発環境になります。このconfigurationをいれていると普通ならWarningになってビルドが成功する場面でもビルドできなくなります。いった横着的な実装はあとあと良くないことを引き起こす危険性があるのでプレビルドの段階で弾いておくべきでしょう。specifiedな設定も上記のベースファイルと一緒に使うことができます。パッケージ管理の自動化iOS開発の現場では外部のライブラリの使用が普通ですが、その管理もできるだけ自動化したいところです。Cocoapodsは言わずと知れたCocoaのパッケージマネージャです。パッケージマネージャを使うことで、依存パッケージの一括管理とアップデートを自動化することができます。Podsを使っているときに起こりがちな問題と、あまり知られていないPodfileの書き方を紹介します。一般的にはPodfileはこんな書き方をすると思います。"BlocksKit"この手軽さがCocoaPodsの持ち味なのですが、もっとプロジェクトが複雑になったときに困る場合があります。CocoaPodsのソースによれば、CocoaPodsは明示的な宣言が無い限り、プロジェクトの先頭にあるターゲットをリンク先として選択します。iPadというターゲットにはリンクされません。インストール前にかならずCocoaPodsのアップデートを行いたいときは?...Podfileでは上記の他に以下のようなDSLを用いることができます。finished!"endこれでpodと実行するとのようにセットアップが完了します。pre_installのブロックでgemのアップデートを実行していますが、systemはrubyでコマンドを実行するためのKernelオブジェクトのメソッドです。Podfileはrubyファイルなのです。Podfileの中には他にも任意のrubyスクリプト+コマンドを書くことができます。installしたあとに生成されるPodfile.lock。なんかよく分からないけど怪しそうだから触らないことが多いと思いますが、実はこのファイルとても重要なのです。中身を見てみると、なにやらPodfileに書いてあることとあまり変わらないことが書いてあるように見えますが、重要な点がふたつ。ひとつはパッケージのバージョン。Podfileにパッケージのバージョンが指定されていなかった場合、最初にインストールされた際のバージョンがここに保存されているのです。installしてもきちんと同じバージョンが入るんですね。updateとか)の環境のcocoapodsのバージョンが記されています。installしようとしたとき、ローカルのcocoapodsのバージョンが違った場合、コンソールにwarningが出るはずです。cocoapodsとして最新バージョンを使うようにしましょう。treeにいれておきましょう。XcodeのカスタムビルドアクションXcodeにはビルド時にシェルスクリプトのカスタムアクションをいれることができます。Phaseから追加することで実現可能です。地味ですがとても便利な機能です。他にも良い使い方をご存じの方がいれば教えてください。Integrationの詳しい説明はhttp://en.wikipedia.org/wiki/Continuous_integrationを見るといいと思います。iOSにおいてCIはあまり一般的ではなく浸透していませんが、webサービスなどでは頻繁なアップデートと安定性の両立という点において重要な位置づけになっています。Serverが普及していないのであまり流行っていません。githubとの連携が必須ですが、無料でセットアップも必要ないのでおすすめです。CIはつい最近Xcode5でのビルドができるようになりました。Builds!)クライアントサイドアプリケーションにおけるテストとCIの意義は個人的には必須だとは思っていないのですが、(UIと密接に関係するクライアントサイドはTry&Errorでテストするしかない部分が多いため)UIと完全に分離したデータモデルやコントローラのクラスではできるだけ作るようにしたほうがいいと思います。あげられると思います。ビルド環境の違いを吸収するという目的もあると思います。チームで開発を行う場合ツールやバージョンを合わせるのが一般的ですが、何かの違いで依存のある変更がgitにコミットされていない場合などに、その起こりうる人的ミスを早期に発見することができます。pushしてしまった、など)というけでCIのためのセットアップをしてみましょう。基本的な設定に関してはこちらの記事などを参考にするといいと思います。CIとかCoverallsとか使うべきCIは基本的にマシンが自動的に行うため、Xcodeなどを操作することはできません。そこで用いられるのがコマンドラインでのビルドツールです。Toolでインストールされるxcodebuildを用いることでもビルドができます。XcodeCIxctoolhttps://github.com/facebook/xctoolxctoolはfacebookが開発したxcodebuildのようなツールで、基本的な機能は同じながらテストの場面で便利な機能があるのでおすすめです。Schemesからsharedにチェックを入れないと他の環境でビルドすることができないので設定しておきましょう。CIがビルドとテストを行うためのファイルを作ります。今回の場合、テストが行われるマシンは普通のMacなので、スクリプトであれば何でも構わないのですがMakefileが一番簡単だと思います。makeRakefileを使うさて、小規模なプロジェクトならば上記のようなMakefileを作るだけでいいのですが、場合によっては何らかの事情でプロジェクトの中に結構な数のターゲットや別々のテストユニットが混在する場合があります。そんなとき、すべてのターゲットをビルドしてテストしたい場合、xctoolではすべてのスキームを選択することはできず、xcodebuildの-alltargetsオプションもworkspaceを使っている場合は使えません。.その上、毎回-workspaceなどの変わらないオプションを付けるのも煩雑です。そこで、Rakefileの登場です。rakeはRubyで記述されたMakefileで、Makefileと異なりより柔軟なタスクの記述ができます。build:XcodeCI:Debugのようにビルドできたらスマートだと思います。はい、そこでこんなRakefileを書きました。"XcodeCI"rakeと打つとあら不思議。プロジェクト中のすべてのスキームをビルドしてテストを行ってくれます。xcworkspaceが持っている情報を読み込んで、スキームとターゲット、コンフィギュレーションに応じて動的にrakeタスクを作っているんですね。infoと打つとこのような情報が表示されます。cocoapodsをお願いします。CIが実行するタスクを記述しましょう。rakeこれだけです。あとはgithubにpushするだけです。初日にもかかわらずあまりiOSとは関係の無いTIPSになってしまいましたが、明日以降素晴らしい記事がぞくぞくと上げられるので大丈夫でしょう:)お疲れさまでした!今回使ったサンプルプロジェクトはhttps://github.com/keroxp/XcodeCIにアップしておいたのでよければ確認して下さい。upLoginユーザーは見つかりませんでした。