DevOpsDaysカンファレンスの創設者としてDevOpsムーブメントをリードするPatrick Debois氏はこの1年，“モバイル版の継続的デリバリ(mobile continuous delivery)”に取り組んでいる。先日のVelocity Europeカンファレンスで氏は，その成果を発表した。
プレゼンテーションでは，ソフトウェア開発サイクルのすべての面に関連するツールやアプリケーション，サービスが多数紹介された。講演の内容は，継続的インテグレーションパイプラインの構築，実行，App Store承認，ビジネス改善という４つのパートに分けられていた。
モバイル継続的インテグレーション(CI/Continuous Integration)の目標は，Webの場合と同じ – 信頼性の高いアプリケーションの構築およびテスト – だが，アプリ署名や数百種というデバイスでのテストなど，モバイル独特の課題も少なくない。氏が紹介したのは，CIパイプラインを完成させるための秘訣やコツ，ツールといったものだ。アプリの実行に関しては，ログ取得や計測，クラッシュレポート，アプリレビューの管理，製品の問題への対処などを取り上げた。継続的デリバリの見地からはおそらく，App Storeによる承認が，モバイル開発の上で最も難しい課題だろう。氏の講演では，アプリの再提出を可能な限り避けるための，いくつかのテクニックやサポートツールを取り上げていた。リモートコンテンツのロード，機能フラグ(feature flag)の広範な利用，ハイブリッドアプリ，メソッド差し替え(Method Swizzling) – ライブパッチの実現手段 – などは，モバイル開発者であれば備えておくべきテクニックだ。そして最後のビジネス改善は，ユーザがアプリをどのように使っているのかを実際の利用パターンから学ぶことや，アプリのダウンロード状況の監視，広範なA/Bテストの実施といった内容だ。
InfoQではDebois氏に，今回の講演について聞くことにした。
InfoQ: 今回の講演では，アプリやツールが盛りだくさんでしたね！モバイル継続的デリバリのパイプラインを構築するためには，どれ程の時間が必要だったのでしょうか？
Patrick Debois: 素晴らしい感想を頂いて，ありがとうございます。パイプラインを始めたのは，2014年の第３四半期でした。
InfoQ: パイプラインを構築する上で，最も難しかった点は何でしたか？
Patrick Debois: Webに公開されているモバイル関連の資料は，そのほとんどが開発面に注目したものです。このことは，コーディングの大部分が独立した開発者によって行われている上に，大部分が１人で作業している人たちであることを考えれば，十分に理解できます。彼らは作業の大半をIDEで行っていますから，成果物をストアにアップロードするのは簡単です。そのため，IDEが処理してくれるような部分についてはあまりドキュメント化されず，難解なままにされているのです。パイプラインを構築しようとすると，その自動化された部分を探し出して，内容を理解しなくてはなりません。この種のインターフェースはドキュメントされていなかったり，もっと悪い場合には，公開されていなかったりすることも多いのです。
InfoQ: iOSとAndroidのエコシステムで，継続的デリバリを行う上で障害の多いのはどちらでしょう？同じ品質のパイプラインを両方に構築することは可能なのでしょうか？
Patrick Debois: 先に述べたような明確なドキュメントが不足していたため，当初はiOSの方がセットアップが困難でした。ですが，適当なツールさえ揃えることができれば(細かな問題すべてに対処するツールを集めるのに１年掛かりましたが)，達成できる品質については同じレベルです。継続的デリバリの最も難しい部分は，実際のデバイスを使ったテストです。今はこの部分を処理するサービスがたくさんありますが，時間を要するプロセスであることに変わりはありません。Androidのエコシステムは多様(画面サイズやブランドによる違いや能力)なため，テストにはiOSよりも1.5倍の時間が必要です。多くの問題を解決した後に，私たちは，ハイブリッドアプリを備えた独自バージョンのChrome開発に着手しました。
一番の問題はもちろん，AppleのApp Storeによるリリース拒否です。 アドホックビルドを使用することでフィードバックを迅速に得ることができますから，テストフェーズではそのような問題はありません。開発を進めるうちに，iOSに関するアーキテクチャ的な作業の大部分は，この手作業プロセスを回避するためのものだということが分かってきました。私たちは，アプリ自体のログ取得と監視をデバイス上でも実施すると同時に，機能フラグやWebViewに加えて，メソッド差し替えなどのテクニックを使用して，a) より高い可視性と，b) 使用時障害へのより迅速なリーチを実現しています。
InfoQ: 最も重要なツールを選ばなくてはならないとしたら，何を選びますか？その理由も教えてください。
Patrick Debois: Twitter/Fabricのツールセットは，本当に役に立っていると思います。テストを担当してくれるユーザへのアプリ配布も簡単ですし，Analyticsを使ってアプリの状況をリアルタイムに知ることができます。最近になってOSSプロジェクトhttps://fastlane.tools/にも参加しているので，今後Fabricは広く普及するのではないかと思います。このプロジェクトは，文書化されていないAPIを数多く手掛けることで，iOSオートメーション関連のコミュニティに大きく貢献しています。
InfoQ: モバイル開発で継続的デリバリに取り組もうとしている人に，何かアドバイスをお願いします。
Patrick Debois: 小さな部分から始めることですね。プロダクトオーナに最新バージョンを提供することが，内部テストを行うよりも大切だと思っています。それぞれのコミットについて最新の状態を誰でも見ることができるという事実が，私たちの開発方法だけでなく，開発しているもの自体の正しさに対する洞察を与えてくれるのです。
同じように，アプリのCIパイプラインばかりに注目しないことです。ログやメトリックを統合することで，シミュレーションではなく，現実の世界でアプリがどのような動作をするのかを知ることができます。Doug Sillars氏がVelocityconfで指摘したように，応答時間の悪さと電池の消耗ほどユーザに不満を持たせるものは他にないのです。