REALITY iOSアプリを支える開発効率化

GREE Tech Conference 2021 で発表された資料です。
https://techcon.gree.jp/2021/session/Session-12

Transcript

1. REALITY iOSアプリを支える 開発効率化 REALITY株式会社 エンジニア かむい
2. 2 自己紹介 • かむい/@kamui_project • 2020.08- REALITY Inc. • VTuber大好きおじさん
3. 3 アジェンダ • 開発効率化を支える改善施策 • CI/CD環境の移行 • 設定専用ミニアプリ • マルチモジュール化
4. 4 アジェンダ • 開発効率化を支える改善施策 • CI/CD環境の移行 • 設定専用ミニアプリ • マルチモジュール化 その前に
5. 5 開発効率化の目的
6. 6 REALITY • 2018.8- VTuberライブ配信視聴 • 2021.11現在 バーチャルライブ配信アプリ • インストールはこちら↓ iOS Android
7. 7 • 2018.8- 8人 • 2021.11現在 26人 ◦ SV, Unity, NativeAppの3チーム ◦ NativeApp Team(iOS: 5, Android: 4) REALITY エンジニアリングチーム規模
8. 8 • 2018.8- 8人 • 2021.11現在 26人 ◦ SV, Unity, NativeAppの3チーム ◦ NativeApp Team(iOS: 5, Android: 4) REALITY エンジニアリングチーム規模 規模感によって以下の2点が変わる ・開発効率化のニーズ ・実際に取り組めるもの
9. 9 • 2018.8- 8人 • 課題: 『定型的な作業を人がしたくない』 REALITY 開発効率化のニーズの変化
10. 10 • 2018.8- 8人 • 課題: 『定型的な作業を人がしたくない』 ◦ ex) アプリのリリース申請作業 REALITY 開発効率化のニーズの変化
11. 11 • 2018.8- 8人 • 課題: 『定型的な作業を人がしたくない』 ◦ ex) アプリのリリース申請作業 • 対応: CI/CD導入 → リリース申請作業の自動化 REALITY 開発効率化のニーズの変化
12. 12 •2021.11現在 26人 • 課題: 『複数人が並行で作業を効率よく進められる仕組み』 ◦ ex) • 1. CI/CDのW/F並行利用増 → オンプレSVに支障 • 2. iOS: 1アプリケーションターゲットのみで開発 → 効率的な並行作業に支障 REALITY 開発効率化のニーズの変化
13. 13 アジェンダ • 開発効率化を支える改善施策 • CI/CD環境の移行 • 設定専用ミニアプリ • マルチモジュール化
14. 14 • 開発効率化を支える改善施策 • CI/CD環境の移行 • 設定専用ミニアプリ • マルチモジュール化 アジェンダ
15. 15 • REALITYのエンジニアチーム全体で実施 開発効率化を支える改善施策
16. 16 • REALITYのエンジニアチーム全体で実施 • 開発効率化を高める取り組みをしたい 開発効率化を支える改善施策
17. 17 • REALITYのエンジニアチーム全体で実施 • 開発効率化を高める取り組みをしたい ◦ 課題: 新規機能開発と並行に実施するコストの高さ 開発効率化を支える改善施策
18. 18 開発効率化を支える改善施策 • REALITYのエンジニアチーム全体で実施 • 開発効率化を高める取り組みをしたい ◦ 問題: 新規機能開発と並行に実施するコストの高さ ◦ 対策: 品質改善だけに使える時間を用意 • 改善Week • 品質改善プロジェクト
19. 19 開発効率化を支える改善施策 • REALITYのエンジニアチーム全体で実施 • 開発効率化を高める取り組みをしたい ◦ 新規機能開発と並行に実施するコストの高さ • 品質改善だけに使える時間を用意 ◦ 改善Week ◦ 品質改善プロジェクト
20. 20 開発効率化を支える改善施策 • REALITYのエンジニアチーム全体で実施 • 開発効率化を高める取り組みをしたい ◦ 問題: 新規機能開発と並行に実施するコストの高さ ◦ 対策: 品質改善だけに使える時間を用意 • 改善Week • 品質改善プロジェクト
21. • 改善Week ◦ 2ヶ月に1度実施 ◦ 品質改善をテーマとしたタスクのみ1週間実施 • Github Issueで作成し以下のラベルのついたもの • bug / devops / enhancement ◦ 新機能開発はエンジニア全員原則STOP 21 開発効率化を支える改善施策
22. • 品質改善プロジェクト ◦ 中長期規模の品質改善の取り組み • 複数テーマを決め、各々チームを作って対応 ◦ 新機能開発とは別にまとまった時間を用意 • 時間は施策規模感によりけり • 施策によって対応時期を分ける必要があれば調整 22 開発効率化を支える改善施策
23. 23 • 開発効率化を支える改善施策 • CI/CD環境の移行 • 設定専用ミニアプリ • マルチモジュール化 REALITY iOSアプリを支える開発効率化
24. 24 • - 2020.11 Jenkins CI/CD環境の移行
25. 25 • - 2020.11 Jenkins ◦ 利用W/F数, エンジニア数, 並列ビルド増加 CI/CD環境の移行
26. 26 • - 2020.11 Jenkins ◦ 利用W/F数, エンジニア数, 並列ビルド増加 ◦ 問題 • CPU負荷増 → iMac Pro再起動 • コロナ禍での物理出社の懸念 CI/CD環境の移行
27. 27 • - 2020.11 Jenkins ◦ 利用W/F数, エンジニア数, 並列ビルド増加 ◦ 問題 • CPU負荷増 → iMac Pro再起動 • コロナ禍での物理出社の懸念 ⇨ クラウド CI/CDツールの検討 CI/CD環境の移行
28. 28 • - 2020.11 Jenkins ◦ 利用W/F, エンジニア数増加 • iMacのCPU使用率が逼迫 → マシン再起動 • コロナ禍での物理出社の懸念 CI/CD環境の移行
29. 29 • - 2020.11 Jenkins ◦ 利用W/F, エンジニア数増加 • iMacのCPU使用率が逼迫 → マシン再起動 • コロナ禍での物理出社の懸念 ⇨ クラウド CI/CDツールの検討 CI/CD環境の移行
30. 30 • 2020.11- Jenkins/Bitrise ◦ Jenkinsから主要なW/Fの移行は完了済み • Bitrise選定理由 ◦ Native Appに特化した機能の多さ ◦ 4vCPUのビルドマシンが使える ◦ 競合サービスと比較した際のコスト(当時) CI/CD環境の移行
31. 31 • bitrise.ymlでW/Fをgit管理 • 主な主要W/F ◦ testing: Build + Unit Test ◦ release: ストア申請 ◦ gardening: CocoaPodsのOSS更新 ◦ testflight_dev: 開発用APIの向き先でTest Flight App作成 CI/CD環境の移行
32. 32 • Slack Botを使いdeployする仕組み CI/CD環境の移行
33. 33 • 良かった点 ◦ iOS開発における物理出社の懸念を取り除くことが出 来た ◦ Jenkinsを稼働させていたW/F数減 • iMac Proの負担を軽減 CI/CD環境の移行
34. • 課題/今後の展望 ◦ Bitriseを今後も使っていくか: △ • 💰の問題: 従量課金制 ◦ 必要であれば柔軟にCI/CD環境を移行できる仕組みを 考慮しておくことが寛容 • ex) Github Actions 34 CI/CD環境の移行
35. • 課題/今後の展望 ◦ Bitriseを今後も使っていくか: △ • 💰の問題: 従量課金制 ◦ 必要であれば柔軟にCI/CD環境を移行できる仕組みを 考慮しておくことが寛容 • ex) Github Actions 35 CI/CD環境の移行 そのために何ができるか
36. • ex) Credentialな情報をどこに格納するか ◦ 現在: Bitrise Secrets • 1つのCI/CDサービスに依存してる仕組み ◦ 今後: 外部のストレージサービスを利用 • ex) GCP Secret Manager 36 CI/CD環境の移行
37. 37 • 開発効率化を支える改善施策 • CI/CD環境の移行 • 設定専用ミニアプリ • マルチモジュール化 REALITY iOSアプリを支える開発効率化
38. 38 • REALITYアプリのデバッグ設定を変更可 • 改善Weekで開発 • 接続先のサーバーの動的差し替えの仕組み 設定専用ミニアプリ
39. 39 • 問題: アプリの設定を変更する際、ビルドをし直す必要 ◦ ex) メンテナンス中の画面を修正, テストしたい • APIのレスポンス値にメンテナンス状態が欲しい • 他の開発に影響, その後の遷移がブロック • 別環境にアクセスできるように変更 • URL文字列の書き換えの都度ビルドが必要 設定専用ミニアプリ
40. 40 • 対応: 設定専用のミニアプリ ◦ サーバーの接続先を動的に差し替え • デバッグアプリをタスキル • 設定アプリ側でURL変更 • デバッグアプリを再起動 ⇨ 指定先のサーバーにアクセス 設定専用ミニアプリ
41. 41 • App Groups ◦ アプリ間でデータ共有を行える仕組み ◦ UserDefaultsを介し、URLの保持・取得を行い サーバーの接続先の動的差し替えを実現 設定専用ミニアプリ
42. 42 • TestFlightなどで配布できる仕組みを用意 ◦ Bitriseに専用W/Fを用意 • iOS開発者以外の人もアプリの設定 変更をできる 設定専用ミニアプリ
43. 43 • 良かった ◦ アプリ側で都度修正, ビルドが不要なサーバー接続先 の動的差し替えを実現 ◦ SwiftUIで画面作成 • プロダクト側から完全に独立し依存問題が無い + UIもシンプルで良かったため活用 設定専用ミニアプリ
44. 44 • 課題/今後の展望 ◦ 設定できる機能の拡充 • アバター向けデバッグメニュー • 端末, アカウント情報の確認 • Firebase RemoteConfigで利用しているflag設定 設定専用ミニアプリ
45. 45 • 開発効率化を支える改善施策 • CI/CD環境の移行 • 設定専用ミニアプリ • マルチモジュール化 REALITY iOSアプリを支える開発効率化
46. • -2021.2 全てのソース: 1Application Target 46 マルチモジュール化
47. • -2021.2 全てのソース: 1Application Target ◦ アーキテクチャ: MVVM, レイヤードアーキテクチャ ◦ XcodeGen導入済み 47 マルチモジュール化
48. • -2021.2 全てのソース: 1Application Target ◦ アーキテクチャ: MVVM, レイヤードアーキテクチャ ⇨ 責務の分離 ◦ ◦ XcodeGen導入済み ⇨ xcodeprojectファイルの競合問題の回避 ◦ 48 マルチモジュール化
49. • 問題1: ビルド時間 ◦ 差分ビルド不可, 修正の都度フルビルド ▪ 機能が増える度にビルド時間も増長 ◦ Unit Testの修正, 追加も一苦労 49 マルチモジュール化
50. • 問題2: 依存問題 ◦ Bastard Injection • DIの仕組みの整備が必要 ◦ 神(Singleton Manager)クラスの存在 • 疎結合な状態を作り出せていない • 新しい技術の導入のし辛さ • 変更した際の影響範囲の広さ etc. 50 マルチモジュール化
51. • 問題 ◦ 依存問題 • Bastard Injection • DIの仕組みの整備不足 • 神(Singleton Manager)クラスの存在 • 疎結合な状態を作り出せていない ◦ 新しい技術の導入のし辛さ ◦ 変更した際の影響範囲の広さ etc. 51 マルチモジュール化 モジュール分離 ＝ マルチモジュール化
52. • 対応 ◦ チームで定期的に話し合う時間を作る ◦ モジュールの切り出し ◦ DIの改善 52 マルチモジュール化
53. • 対応 ◦ チームで定期的に話し合う時間を作る ◦ モジュールの切り出し ◦ DIの改善 53 マルチモジュール化
54. 54 • 対応: チームで定期的に話し合う時間を作る ◦ REALITY iOSのアーキテクチャについて話し合う時間 を新たに用意 ⇨ あきべん。 ◦ 週に1回・iOSメンバー全員が参加し実施 ◦ 最近の主な話題 • マルチモジュール化, SwiftUIの導入, DI改善 etc. マルチモジュール化
55. 55 • 対応: チームで定期的に話し合う時間を作る ◦ 理由: チームの協力が必要不可欠 • 影響範囲が膨大 • 目的 + 新しい設計ルールをチーム全員が理解, 協力しあう必要 • 目的に沿っているか定期的に確認する時間が必要 マルチモジュール化
56. 56 • 対応: チームで定期的に話し合う時間を作る ◦ マルチモジュール化について話したこと • モジュール構成 • 切り出す優先順位 • featureモジュール内の構成 マルチモジュール化
57. • 対応 ◦ チームで定期的に話し合う時間を作る ◦ モジュールの切り出し ◦ DIの改善 57 マルチモジュール化
58. 58 マルチモジュール化
59. • Coreモジュール ◦ エラー処理 ◦ 既存のEntity ▪ 新規分はfeatureモジュールに ◦ 新規API Response ◦ Infrastructure層のクラス 59 マルチモジュール化
60. • Coreモジュール ◦ 多くのclassでprotocolによる抽象化 → 移行が容易 • Domain, Infrastructure層の移行は可視性の変更だ けで対応ができた ◦ 1ファイルに複数の定義があるor多くの依存の持ってい るオブジェクトの移行は大変 60 マルチモジュール化
61. • extension系モジュール ◦ AppleFramework Extensions • UIKit, Foundation系 ◦ ThirdPartyLib Extensions • RxSwift等のOSS系 ◦ Reality Extensions • 上記2つのモジュールのWrapper • どのextension系モジュールをimportすべきかを 意識しない作り 61 マルチモジュール化
62. • Loggerモジュール ◦ ログ関連処理 • Firebase Analytics, Crashlytics, Performance • MetricsKit 62 マルチモジュール化
63. • RealityResourcesモジュール ◦ Color Asset ◦ Localization 63 マルチモジュール化
64. • RealityUIComponentsモジュール ◦ モジュールを横断して利用するUI Component ▪ Toast, Alert, Button, Cell等 64 マルチモジュール化
65. • RealityUIComponentsモジュール ◦ IBLinter • Interface Builderファイルの静的検査 • custom_moduleチェック • その他: 制約重複, autolayout不正チェック ◦ 既存のwarning数を減らした上で利用して いきたい 65 マルチモジュール化
66. • Featureモジュール 66 マルチモジュール化
67. • Featureモジュール ◦ 機能単位のミニアプリを作成 ◦ 必要最低限の依存解決でビルド実行 • ビルド時間 平均9秒 • ビルド時間の大幅な改善 • プレビューサイクルの大幅な改善 ◦ 画面遷移も通常の導線を跨ぐ必要無し 67 マルチモジュール化
68. • 対応 ◦ チームで定期的に話し合う時間を作る ◦ モジュールの切り出し ◦ DIの改善 68 マルチモジュール化
69. • 対応: DI改善 ◦ uber/needleをDIシステムに採用 • 理由 • 依存解決コードを自動生成 • 登場人物が少ない • 安全で無い依存注入はビルドエラーで変数名, 型, 階層を指摘 69 マルチモジュール化
70. 70 マルチモジュール化
71. 71 マルチモジュール化
72. 72 マルチモジュール化
73. 73 マルチモジュール化
74. 74 マルチモジュール化
75. • 対応: DI改善 ◦ アプリ起動時〜ログイン画面まで導入済 • 詳細はnoteの記事をご覧ください 75 マルチモジュール化
76. • 良かった点 ◦ チームで定期的に話し合う時間を作る • 目的や方針の認識確認をする時間が取れた 76 マルチモジュール化
77. • 良かった点 ◦ チームで定期的に話し合う時間を作る • 目的や方針の認識確認をする時間が取れた • ex) 移行対象のファイル 77 マルチモジュール化
78. • 良かった点 ◦ モジュール切り出し • 多くのclassでprotocolによる抽象化 • Domain, Infrastructure層の移行が可視性の 変更だけで対応できた • Unit Testも充実していたため移行時の心理的安全 性も高かった 78 マルチモジュール化
79. • 良かった点 ◦ モジュール切り出し • featureモジュール • ミニアプリの作成 ◦ プレビューサイクルの大幅な改善 79 マルチモジュール化
80. • 課題/今後の展望 ◦ featureモジュールの拡充 • 既存機能との依存関係を持たない部分のみ実現 • 神クラスによる依存問題解決に取り組みつつ、 featureモジュールを拡充していきたい 80 マルチモジュール化
81. • 課題/今後の展望 ◦ モジュール形式 • framework → Swift Package • project.pbxproj の変更に悩まされない ◦ 将来的なXcodeGenからの脱却 • link設定はdynamic ◦ 起動時間短縮のためにstatic linkの検討も 合わせて実施予定 81 マルチモジュール化
82. 82 REALITY iOS 開発効率化の今後の展望
83. 83 REALITY iOS 開発効率化の今後の展望
84. 84 REALITY iOS 開発効率化の今後の展望
85. 85 REALITY iOS 開発効率化の今後の展望
86. • マルチモジュール化 ◦ featureモジュールの拡充 • ミニアプリを使った開発効率化の改善 • モジュール形式にSwift Pacakgeを採用 • 将来的なXcodeGenの脱却 86 REALITY iOS 開発効率化の今後の展望
87. • 通信速度改善を目指した取り組み ◦ Protocol Buffers ◦ スキーマ定義 • SV/Native Appでソースコードの自動生成 • 実装, コミュニケーションコスト双方の削減 87 REALITY iOS 開発効率化の今後の展望
88. • SwiftUIを画面実装の選択肢に ◦ 実装コストの削減 ◦ プレビュー機能を活用したプレビューサイクルの改善 ◦ iOS14以上をサポートバージョン • リストの実装などで恩恵を得られるのも良い選定 ポイントになっている 88 REALITY iOS 開発効率化の今後の展望
89. 89 REALITY iOS 開発効率化の今後の展望 『複数人が並行で作業を効率よく進められる仕組み』 に引き続き取り組み、開発効率化を高めていきたい
90. 90 note meety We’re Hiring!