「JapanTaxi」iOS アプリを継続的かつ安定してリリースするための取り組み

Proprietary and Conﬁdential ©2017 JapanTaxi, Inc. All Rights Reserved
「JapanTaxi」iOS アプリを
継続的かつ安定してリリースするための取り組み

View Slide

⾃⼰紹介
2
Yosuke Imairi
• JapanTaxi (2017.5 -)
• iOS app Developer

View Slide

3
「JapanTaxi」アプリの開発体制
＆
iOS ユニットの複数⼈開発における取り組み

View Slide

「JapanTaxi」アプリを⽀えるチーム/ユニット
4
Server iOS Android
ユニット

View Slide

5
Server iOS Android
チーム

View Slide

6
Server iOS Android
PM

View Slide

LeSS (Large-Scale Scrum)
7

View Slide

8
Server iOS Android
PM
プロジェクト A
プロジェクト B

View Slide

9
iOS ユニットとして
安定してアプリを継続的にリリースするにはどうすればよいか

View Slide

安定して継続的なリリースを⾏うために
10
- 1．コードの品質を保つ
- アーキテクチャやコーディング規約に沿った設計や実装
- バグが⽣まれにくいようにする
- 提供したい機能の開発が遅れることを防ぐ
- 2．効率よく複数⼈開発する
- 迅速なコードレビューの意識付け
- 共通作業の⾃動化
- 3．リリースサイクルの明確化

View Slide

1．コードの品質を保つ
11

View Slide

SwiftLint
12
- 基本的に //swiftlint:disable は禁⽌
- 乱⽤すると SwiftLint を導⼊した意味がなくなるから
- すべてのルールを有効後、無効にすべきルールを絞る
- 無効にしたルールは理由を記述する

View Slide

- 既存のビジネスロジックが壊れないようにするための担保
- なるべく実装時に書くように⼼がける（仕様を忘れないように）
- 複数⼈開発では、誰がどの機能を修正するか分からない
- QA での⼿戻りを少なくするため
- QA チームの負担を軽減
- バグ修正の時間を減らして、本来の開発に集中する
Unit Test
13

View Slide

- Unit Test のテンプレート（Quick/Nimble, Mockの定義）
- モックの⾃動⽣成
- Unit Test を書ける状態を保つ（DI etc..）
- ⽇頃の開発時に⼼がける必要あり
Unit Test を書くにあたっての⼼理的障壁を下げる
14

View Slide

15
https://blog.japantaxi.co.jp/2019/12/25/6656
JapanTaxi iOS UnitTest

View Slide

2．効率よく複数⼈開発する
16
（コードレビュー）

View Slide

- コードの品質を保つためにコードレビューを⽇々⾏っている
- コードに対するコミュニケーションの場
- コードの誤りの指摘以外にも、気になったことは気軽にコメント
コードレビュー
17

View Slide

- 対応したこと
- 対応していないこと
- 対応すべき範疇を超えているもの
- 別の Pull Request で対応するもの
- スクリーンショットなどで修正差分を提⽰
- 微妙な実装になったところ、懸念点
Pull Request の Description
18
レビュアーとの円滑なコミュニケーションを図る

View Slide

- ( ´-`).。oO (みんな忙しくてレビューしてくれない…)
- Pull Request を⻑時間放置することは危険
- マージ先とのコンフリクト解消コスト
- 何を修正したか⾃分が忘れる
- 途中でレビュアーが交代
Pull Request が溜まりがち問題
19

View Slide

Pull Request が溜まりがち問題
20
Pull Panda ͷ׆༻ͯ͠ίʔυϨϏϡʔ΁ͷҙࣝ෇͚

View Slide

Pull Assigner
21
- Pull Assigner でレビュアーの⾃動アサイン
- レビューの負担を均⼀化
- レビュアーは 1 ⼈を選定し明確化する

View Slide

Pull Analytics
22
- 24時間以内にレビューがされたかどうかの確認
- iOS ユニットの定例 MTG で毎週確認（⽬標: 90% ）

View Slide

Pull Reminder
23
- 朝とお昼に Slack のチャンネルにリマインドを投稿
- 送りすぎると耐性がつくので注意

View Slide

⾃動レビュー
24
- 機械的にレビューできることは Bot で（レビュアーの負担軽減）
- SwiftLint の警告をコメント
- 使われていない定義を指摘
- Ruby スクリプトで未使⽤のメソッドやプロパティやクラスを
精査し、Danger を利⽤してコメント

View Slide

2．効率よく複数⼈開発する
25
（⾃動化）

View Slide

共通の作業を⾃動化
26
- ユニットメンバの共通作業を make コマンドで統⼀
- 環境構築
- ライブラリの導⼊
- テンプレートの導⼊
- モック⽣成
- GraphQL の schema 更新や API.swift の⽣成
- Bitrise のワークフローを作成し、様々な作業を⾃動化
誰でも安⼼して同じ作業が⾏える仕組みの構築
CIの活⽤で開発作業時間を確保

View Slide

リリースまわりの作業を⾃動化
27
- Slack から TestFlight へのアップロード
- DEV, STG, PROD
/japantaxi-passenger-ios b:release/4.4.15|w:testflight
- Slack からコードフリーズ作業
- リリースブランチ作成
- バージョン更新
- Branch protection rules 追加
- Beta で配信
/japantaxi-passenger-ios b:master|w:code-freeze|ENV[RELEASE_APP_VERSIION]:4.4.16

View Slide

28
https://blog.japantaxi.co.jp/2019/12/18/6190
JapanTaxi iOS Bitrise

View Slide

3．リリースサイクルの明確化
29

View Slide

リリースサイクル
30
- 開発したものは素早くユーザに届けたい
- 安⼼してリリースしたい
- 無理なくリリースできるサイクル
- 曜⽇を固定化すると他部署と調整がしやすい
- 予定された⽇に間に合わなかった場合は次のリリースに持ち越し

View Slide

毎週⾦曜⽇にコードフリーズ (※)
31
(※) QAに提出するバイナリの作成
コードフリーズ

View Slide

コードフリーズの翌週にQA
32
QA

View Slide

毎週⾦曜⽇に審査提出
33
QA
審査提出

View Slide

毎週⽔曜⽇にリリース
34
QA
審査提出
リリース

View Slide

毎週⽔曜⽇にリリース
35

View Slide

このような取り組みの結果…
36

View Slide

安定して継続的なリリース
37
- バグ修正や機能改善、新機能などを毎週リリース
- 2019 年は合計 41 回リリース
- バグによる Hotﬁx は 2 回
- 複数チームでプロジェクトを進める
- 数ヶ⽉かかる⼤規模な開発と並⾏して、細かな改
善も継続的に⾏えた
- リリースサイクルの明確化

View Slide

2020年もがんばります
38

View Slide

จষɾը૾౳ͷ಺༰ͷແஅసࡌٴͼෳ੡౳ͷߦҝ͸͝ԕྀ͍ͩ͘͞ɻ
Proprietary and Conﬁdential ©2017 JapanTaxi, Inc.
All Rights Reserved
˟102-0094ɹ౦ژ౎ઍ୅ా۠لඌҪொ3-12
3-12 Kioicho Chiyoda-ku, Tokyo 102-0094 Japan
TEL 03-6265-6265ɹFAX 03-3239-8115
www.japantaxi.co.jp

View Slide

「JapanTaxi」iOS アプリを継続的かつ安定してリリースするための取り組み

「JapanTaxi」iOS アプリを継続的かつ安定してリリースするための取り組み

Yosuke Imairi

More Decks by Yosuke Imairi

Other Decks in Technology

Featured

Transcript