iOSアプリにおけるリリースフローとCI環境

Copyright © DeNA Co.,Ltd. All Rights Reserved.
iOS Creators' Meetup vol.2
2016/10/14(Fri)
平田敏之@DeNA
iOSアプリにおけるリリースフロー
とCI環境

自己紹介
 平田敏之@DeNA
⁃ 経歴
• GWの開発 → ホムペサービスの開発、iOSアプリの開発 → SWET
⁃ SWET(Software Engineer in Test)
• 事業サポートチーム / テスト基盤チーム
• ミッション
⁃ DeNAサービス全般の品質向上
⁃ DeNAエンジニアの開発生産性向上
⁃ 私がやっていること(の一部)
• クライアントアプリ周りのテスト戦略、自動テストの開発
• CI/CD環境整備
• テスト基盤環境の開発
• iOS Test Night 主催
⁃ http://testnight.connpass.com/event/41323/

はじめに
 リリースフローの1サイクルに時間がかかっていませんか？
⁃ (例えば)開発・検証のサイクルに時間がかかっていませんか？
• このサイクル内でコミュニケーションの発生が多くありませんか？
• 色々と手動でやっていませんか？
 CI環境をどこまで導入できていますか？
⁃ 手動で色々やっている箇所がありませんか？
⁃ 開発のメンバーだけが利用していませんか？
⁃ Xcode、Jenkins、BTS、Slackなどを何度も行き来していませんか？
• コンテキストスイッチが発生しまくっていませんか？

iOSアプリにおけるリリースフロー(例)
特に(2)のサイクルをいかに「簡単」に「すばやく」まわせるかが大事
 企画
↓
 (デザイン)
 開発
 検証
 iTunes ConnectへのバイナリUpload
↓
 Appleへ審査提出
⁃ 各種データの更新
 Appleの審査
 AppStoreへリリース
 リリース後検証
(1)
(2)
(3)
※これ以外にServerのDeployもあるのが一般的です。

CI環境がない世界
開発検証
iTunes Connect
Archive → Upload to AppStore
(1) 機能実装・修正
(2) Xcodeを使ってアプリを端末にインストール
(3) 検証 / バグがあれば(1)へ
(4) Xcodeを使ってProduct -> Archive
(5) XcodeのOrganizerを使ってUpload to App Store

CI環境がある世界
開発検証 iTunes Connect
upload
deploy
DeployGate / Fabric etc
auto test
SwiftLint
etc
bot
Remote Access API
BTS
mention
mention

ざっくりとした流れ
 開発
⁃ 実装
• (1) 静的解析
• (2) アプリのビルド
• (3) アプリの自動テスト
• (4) コードレビュー(第三者が関わる)
⁃ (1)〜(3)までを終えてから
 検証
⁃ (1) 検証対象となるアプリのインストール
• JenkinsやDeployGateなどからインストール
⁃ (2) バグ報告
• BTSに起票
 iTunes Connectへのupload
⁃ 検証で問題なければリリース候補としてupload

CI環境がある場合のリリースフロー (1/2)
 開発
⁃ 静的解析(SwiftLint etc)
• ここらへんをコードレビューで指摘するのは時間の無駄
⁃ アプリのビルド(fastlane gym)
• ※マシンパワーを良くしてビルド時間を短くする※
• ビルドできないようなものをレビューに出さない
⁃ アプリの自動テスト(XCUITest / EarlGrey / Appium)
• ※並列化などで実行時間を短くする※
• テストが通らないものをレビューに出さない
⁃ アプリのデプロイ(fastlane deploygate etc)
• 容量問題がなければ毎ビルド毎にデプロイしてしまうのが良い
⁃ コードレビュー
• ※一番ヒューマンコストが高いので無駄なことは避ける※
• 設計周りについて相談があれば早めにPull Requestを出す

CI環境がある場合のリリースフロー (2/2)
 検証
⁃ 検証対象のアプリのインストール(DeployGate etc)
• 検証担当者自身でインストール
⁃ バグがあれば指摘(JIRA etc)
• BTSに起票するとSlackで担当者宛にmentionが来る
 検証終了(fastlane deliver)
⁃ リリース候補版としてiTunes Connectにupload
• bot(またはJenkins)を用いてupload
⁃ 場合によっては、1サイクルの間にいくつもuploadされる

CI環境があることによるメリット(の一部)
 集中するべきものに集中できる。
⁃ コンテキストスイッチは極力少なめに。
 常に動くアプリが存在する。
⁃ 久しぶりにアプリをビルドしたらできなかったとかは無い。
⁃ アプリを見たい人にすぐ渡すことが出来る。
 常にある程度の品質を担保した状態になっている。
⁃ ある程度＝何をおこなっているか次第

まとめ
 リリースフローをいかに「簡単」に「すばやく」まわせるかが大事
⁃ そのためにはCI環境は必須
 CI環境はプロダクトに関わる全ての人にとって必要な環境
⁃ 誰もが利用できるようにするのが良い
 CI環境をしっかりと用意してリリースを楽にしましょう
⁃ CI環境の導入による苦労話(運用コストや属人化)はまた別の話
• これもある程度は軽減できます

iOSアプリにおけるリリースフローとCI環境

More Related Content

What's hot (20)

Similar to iOSアプリにおけるリリースフローとCI環境 (20)

More from Toshiyuki Hirata (7)

Recently uploaded (9)

iOSアプリにおけるリリースフローとCI環境