REALITY iOSアプリの開発効率化を支える取り組み
•Download as PPTX, PDF•
0 likes•1,198 views
The document discusses development efficiency improvements made at REALITY Inc. to support their iOS app. As the engineering team grew from 8 to 26 people, the need increased for tools that allow parallel work without interference. Changes included migrating the CI/CD environment from Jenkins to Bitrise for increased capacity and flexibility, creating a mini-app for dynamically changing server connections to enable testing without rebuilds, and planning to split the iOS app into multiple modules. The goal is to enhance efficiency through measures like dedicated improvement weeks while continuing new feature development.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to REALITY iOSアプリの開発効率化を支える取り組み
Similar to REALITY iOSアプリの開発効率化を支える取り組み (20)
More from gree_tech
More from gree_tech (20)
Recently uploaded
Recently uploaded (20)
REALITY iOSアプリの開発効率化を支える取り組み
- 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環境の移行 • 設定専用ミニアプリ • マルチモジュール化 アジェンダ
- 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環境の移行
- 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 マルチモジュール化
- 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 マルチモジュール化
- 86. • マルチモジュール化 ○ featureモジュールの拡充 • ミニアプリを使った開発効率化の改善 • モジュール形式にSwift Pacakgeを採用 ● 将来的なXcodeGenの脱却 86 REALITY iOS 開発効率化の今後の展望
- 87. • 通信速度改善を目指した取り組み ○ Protocol Buffers ○ スキーマ定義 • SV/Native Appでソースコードの自動生成 ● 実装, コミュニケーションコスト双方の削減 87 REALITY iOS 開発効率化の今後の展望
- 88. • SwiftUIを画面実装の選択肢に ○ 実装コストの削減 ○ プレビュー機能を活用したプレビューサイクルの改善 ○ iOS14以上をサポートバージョン • リストの実装などで恩恵を得られるのも良い選定 ポイントになっている 88 REALITY iOS 開発効率化の今後の展望
- 91. 91