Cookpad Tech Kitchen #2 ~iOSアプリの継続的デリバリーへの取り組み~に参加してきたので記事を書きます。言葉で頑張って説明するより図を見てもらった方が早いものに関してはざっくり端折っています。

iOSアプリの継続的デリバリーへの取り組み @松尾和昭氏

20160913 cookpad ios_jp from Kazuaki MATSUO

www.slideshare.net

開発プロセス / フロー
- 昔はモバイルファースト室が独立していたが、今は各サービス部署に属するようになった
開発サイクル
- 基本、月1回リリース
- PR 締め切り -> コードフリーズ -> サブミット -> リリース
テスト戦略
- ピラミッド
  - Enormous / Large / Medium / Small
  - 詳しくはAndroid/iOSアプリのテストの区分戦略へ
  - 上に行くに連れて時間がかかるテストになってくる
  - ピラミッドに加えてマニュアルテストも行う
- L/Eテストで何を確認するか
  - GUIテスト、シナリオテスト
    - 1つの端末で200シナリオくらい
    - 画面遷移ベースでキャプチャを撮ってやっている
  - 予期しないレイアウトの崩れ
    - アラートボタンの左右の配置が逆になっている、など
- 自動化されたテストの利点例
```
  * テスト実行、判定を機械にやらせている間、人は創造的なことに時間を割ける
```
実行環境の組み合わせ
- 6~8端末チェック
- シミュレータも使う
設計
- 責務の文理
保守
- 毎リリース必ず影響するのはシナリオ
クラッシュの割合
- 99.9%以上はクラッシュなし
UI Testingの動機
- できるだけ自動化して人手が必要なところに集中する必要があった
Appium
- クックパッドアプリの開発を支援するAppiumの話し - スライド
EarlGrey
- iOS8以上が対象
- XCUI Testは不安定なのでこっち使う

テストが徹底的に実施されているということをうかがい知ることができた発表でした。多くのユーザを抱えているのに99.9%も正常に動いているのはこれだけしっかりとテストしているからなんですね。真似できるところから真似していきたいと思いました。

CDC Testing on iOS @三木康暉氏

課題
- サーバサイドの変更によるサービスの破壊の検知
- サーバ、クライアント開発者間での仕様共有の必要性
CDC Testingとは
- Consumer-Driven Contract Testing
- APIとクライアント間の整合性をテストするためのテスト手法
用語
- Provider / APIを提供する側 = APIサーバ
- Consumer / 利用する側 = iOSアプリ
- Contract / APIの仕様
Pact
- CDC testingのためのフレームワーク
- 実践 Pact:マイクロサービス時代のテストツール - クックパッド開発者ブログ
- consumer側で Contractを記述したファイルを生成Pact File
- pact Brokerにアップしておく
- APIサーバがレスポンスを返した時にPact fileと合っているかCIで確認
Pact fileを生成する流れ
- 1. Unit Test起動時にPact Mock Serverを立ち上げる
- 1. モックサーバにリクエストとレスポンスの組を登録する
- 1. ユニットテストから持っくサーバに対してリクエストを送り、対になるレスポンスを返す
- 1. 受け取ったレスポンスをクライアント側で検査し、正しければモックサーバに伝える Pactファイルが生成
- 1. モックサーバがPactファイルを生成するので、Brokerにアップロードする
Phakchi
- Pactのテストケースを楽に記述するライブラリ
導入してみて
- 一応はAPIの変更に気づけるようになった
- まだまだiOSのテストケースが少ないので未知数
問題点
- CI運用
- マージタイミングの問題
  - サーバサイド、クライアントサイドで同時
- 巨大なレスポンスへの対応

現職では1つの案件を持ったら1人でクライアント側もサーバ側も同時に直しているのでそんなに齟齬が出ないようになっていますがサーバ絡みのテストは大事ですよね（ただししっかりテストを書いているとは言っていない）。

「めんどくさいと思ったらライブラリ作っちゃえ」という姿勢はさすがクックパッドさんだなと思いました。意識と技術レベルが高い。

クックパッド iOSアプリの開発フロー @森川慎太郎氏

クックパッドの開発フロー
- issue締め切り
  - 次のバージョンに入れたい変更を列挙
リリースマネージャー
- 当番制
- 次のリリースのスケジュールを管理
- 各種締め切り守るようメンバーをつつく
開発ルール
- レビュー
  - LGTMが2人から出ないとだめ
- 開発者が互いにレビューしあう
- デザイン変更がある場合はデザイナーによるレビュー
- レビューをする時間、される時間が速くサイクルを回すボトルネック
レビューの負荷を下げる工夫
- コードレビューに費やす時間を短くする - クックパッド開発者ブログ
- 開発速度を上げるための Pull-Request のつくり方 - クックパッド開発者ブログ
- ラベル
- slack通知
  - 「LGTM」「レビュー」文字列を含むコメントのみ通知来るように
- スクリーンショットの活用
  - UIの変更前後を視覚的に説明
Dokumi
- Dokumi (日本語) - クックパッド開発者ブログ
- CIでコードをチェックしてPRにコメントしてくれるツール
- AutoLayoutのmisplaceも指摘してくれる
課題と改善
- Pull-Requestは溜まる
- 振り返り会
  - 開発に関するKPT
  - 2週間に1回くらい