iosアプリにおけるリリースフローとci環境

Copyright © DeNA Co.,Ltd. All Rights Reserved.

iOS Creators' Meetup vol.22016/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/

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環境

Technology