Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

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

gree_tech
PRO

November 11, 2021
Tweet

More Decks by gree_tech

Other Decks in Technology

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!

  91. 91