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

by gree_tech

Slide 1

Slide 1 text

REALITY iOSアプリを支える開発効率化 REALITY株式会社エンジニアかむい

Slide 2

Slide 2 text

2 自己紹介 ● かむい/@kamui_project ● 2020.08- REALITY Inc. ● VTuber大好きおじさん

Slide 3

Slide 3 text

3 アジェンダ • 開発効率化を支える改善施策 • CI/CD環境の移行 • 設定専用ミニアプリ • マルチモジュール化

Slide 4

Slide 4 text

4 アジェンダ • 開発効率化を支える改善施策 • CI/CD環境の移行 • 設定専用ミニアプリ • マルチモジュール化その前に

Slide 5

Slide 5 text

5 開発効率化の目的

Slide 6

Slide 6 text

6 REALITY • 2018.8- VTuberライブ配信視聴 • 2021.11現在バーチャルライブ配信アプリ • インストールはこちら↓ iOS Android

Slide 7

Slide 7 text

7 • 2018.8- 8人 • 2021.11現在 26人 ○ SV, Unity, NativeAppの3チーム ○ NativeApp Team(iOS: 5, Android: 4) REALITY エンジニアリングチーム規模

Slide 8

Slide 8 text

8 • 2018.8- 8人 • 2021.11現在 26人 ○ SV, Unity, NativeAppの3チーム ○ NativeApp Team(iOS: 5, Android: 4) REALITY エンジニアリングチーム規模規模感によって以下の2点が変わる・開発効率化のニーズ・実際に取り組めるもの

Slide 9

Slide 9 text

9 • 2018.8- 8人 • 課題: 『定型的な作業を人がしたくない』 REALITY 開発効率化のニーズの変化

Slide 10

Slide 10 text

10 • 2018.8- 8人 • 課題: 『定型的な作業を人がしたくない』 ○ ex) アプリのリリース申請作業 REALITY 開発効率化のニーズの変化

Slide 11

Slide 11 text

11 • 2018.8- 8人 • 課題: 『定型的な作業を人がしたくない』 ○ ex) アプリのリリース申請作業 • 対応: CI/CD導入 → リリース申請作業の自動化 REALITY 開発効率化のニーズの変化

Slide 12

Slide 12 text

12 •2021.11現在 26人 • 課題: 『複数人が並行で作業を効率よく進められる仕組み』 ○ ex) • 1. CI/CDのW/F並行利用増 → オンプレSVに支障 • 2. iOS: 1アプリケーションターゲットのみで開発 → 効率的な並行作業に支障 REALITY 開発効率化のニーズの変化

Slide 13

Slide 13 text

13 アジェンダ • 開発効率化を支える改善施策 • CI/CD環境の移行 • 設定専用ミニアプリ • マルチモジュール化

Slide 14

Slide 14 text

14 • 開発効率化を支える改善施策 • CI/CD環境の移行 • 設定専用ミニアプリ • マルチモジュール化アジェンダ

Slide 15

Slide 15 text

15 • REALITYのエンジニアチーム全体で実施開発効率化を支える改善施策

Slide 16

Slide 16 text

16 • REALITYのエンジニアチーム全体で実施 • 開発効率化を高める取り組みをしたい開発効率化を支える改善施策

Slide 17

Slide 17 text

17 • REALITYのエンジニアチーム全体で実施 • 開発効率化を高める取り組みをしたい ○ 課題: 新規機能開発と並行に実施するコストの高さ開発効率化を支える改善施策

Slide 18

Slide 18 text

18 開発効率化を支える改善施策 • REALITYのエンジニアチーム全体で実施 • 開発効率化を高める取り組みをしたい ○ 問題: 新規機能開発と並行に実施するコストの高さ ○ 対策: 品質改善だけに使える時間を用意 ● 改善Week ● 品質改善プロジェクト

Slide 19

Slide 19 text

19 開発効率化を支える改善施策 • REALITYのエンジニアチーム全体で実施 • 開発効率化を高める取り組みをしたい ○ 新規機能開発と並行に実施するコストの高さ • 品質改善だけに使える時間を用意 ○ 改善Week ○ 品質改善プロジェクト

Slide 20

Slide 20 text

20 開発効率化を支える改善施策 • REALITYのエンジニアチーム全体で実施 • 開発効率化を高める取り組みをしたい ○ 問題: 新規機能開発と並行に実施するコストの高さ ○ 対策: 品質改善だけに使える時間を用意 ● 改善Week ● 品質改善プロジェクト

Slide 21

Slide 21 text

• 改善Week ○ 2ヶ月に1度実施 ○ 品質改善をテーマとしたタスクのみ1週間実施 • Github Issueで作成し以下のラベルのついたもの ● bug / devops / enhancement ○ 新機能開発はエンジニア全員原則STOP 21 開発効率化を支える改善施策

Slide 22

Slide 22 text

• 品質改善プロジェクト ○ 中長期規模の品質改善の取り組み • 複数テーマを決め、各々チームを作って対応 ○ 新機能開発とは別にまとまった時間を用意 • 時間は施策規模感によりけり • 施策によって対応時期を分ける必要があれば調整 22 開発効率化を支える改善施策

Slide 23

Slide 23 text

23 • 開発効率化を支える改善施策 • CI/CD環境の移行 • 設定専用ミニアプリ • マルチモジュール化 REALITY iOSアプリを支える開発効率化

Slide 24

Slide 24 text

24 • - 2020.11 Jenkins CI/CD環境の移行

Slide 25

Slide 25 text

25 • - 2020.11 Jenkins ○ 利用W/F数, エンジニア数, 並列ビルド増加 CI/CD環境の移行

Slide 26

Slide 26 text

26 • - 2020.11 Jenkins ○ 利用W/F数, エンジニア数, 並列ビルド増加 ○ 問題 • CPU負荷増 → iMac Pro再起動 • コロナ禍での物理出社の懸念 CI/CD環境の移行

Slide 27

Slide 27 text

27 • - 2020.11 Jenkins ○ 利用W/F数, エンジニア数, 並列ビルド増加 ○ 問題 • CPU負荷増 → iMac Pro再起動 • コロナ禍での物理出社の懸念 ⇨ クラウド CI/CDツールの検討 CI/CD環境の移行

Slide 28

Slide 28 text

28 • - 2020.11 Jenkins ○ 利用W/F, エンジニア数増加 • iMacのCPU使用率が逼迫 → マシン再起動 • コロナ禍での物理出社の懸念 CI/CD環境の移行

Slide 29

Slide 29 text

29 • - 2020.11 Jenkins ○ 利用W/F, エンジニア数増加 • iMacのCPU使用率が逼迫 → マシン再起動 • コロナ禍での物理出社の懸念 ⇨ クラウド CI/CDツールの検討 CI/CD環境の移行

Slide 30

Slide 30 text

30 • 2020.11- Jenkins/Bitrise ○ Jenkinsから主要なW/Fの移行は完了済み • Bitrise選定理由 ○ Native Appに特化した機能の多さ ○ 4vCPUのビルドマシンが使える ○ 競合サービスと比較した際のコスト(当時) CI/CD環境の移行

Slide 31

Slide 31 text

31 • bitrise.ymlでW/Fをgit管理 • 主な主要W/F ○ testing: Build + Unit Test ○ release: ストア申請 ○ gardening: CocoaPodsのOSS更新 ○ testflight_dev: 開発用APIの向き先でTest Flight App作成 CI/CD環境の移行

Slide 32

Slide 32 text

32 • Slack Botを使いdeployする仕組み CI/CD環境の移行

Slide 33

Slide 33 text

33 • 良かった点 ○ iOS開発における物理出社の懸念を取り除くことが出来た ○ Jenkinsを稼働させていたW/F数減 • iMac Proの負担を軽減 CI/CD環境の移行

Slide 34

Slide 34 text

• 課題/今後の展望 ○ Bitriseを今後も使っていくか: △ • 💰の問題: 従量課金制 ○ 必要であれば柔軟にCI/CD環境を移行できる仕組みを考慮しておくことが寛容 • ex) Github Actions 34 CI/CD環境の移行

Slide 35

Slide 35 text

• 課題/今後の展望 ○ Bitriseを今後も使っていくか: △ • 💰の問題: 従量課金制 ○ 必要であれば柔軟にCI/CD環境を移行できる仕組みを考慮しておくことが寛容 • ex) Github Actions 35 CI/CD環境の移行そのために何ができるか

Slide 36

Slide 36 text

• ex) Credentialな情報をどこに格納するか ○ 現在: Bitrise Secrets • 1つのCI/CDサービスに依存してる仕組み ○ 今後: 外部のストレージサービスを利用 • ex) GCP Secret Manager 36 CI/CD環境の移行

Slide 37

Slide 37 text

37 • 開発効率化を支える改善施策 • CI/CD環境の移行 • 設定専用ミニアプリ • マルチモジュール化 REALITY iOSアプリを支える開発効率化

Slide 38

Slide 38 text

38 • REALITYアプリのデバッグ設定を変更可 • 改善Weekで開発 • 接続先のサーバーの動的差し替えの仕組み設定専用ミニアプリ

Slide 39

Slide 39 text

39 • 問題: アプリの設定を変更する際、ビルドをし直す必要 ○ ex) メンテナンス中の画面を修正, テストしたい • APIのレスポンス値にメンテナンス状態が欲しい ● 他の開発に影響, その後の遷移がブロック • 別環境にアクセスできるように変更 ● URL文字列の書き換えの都度ビルドが必要設定専用ミニアプリ

Slide 40

Slide 40 text

40 • 対応: 設定専用のミニアプリ ○ サーバーの接続先を動的に差し替え • デバッグアプリをタスキル • 設定アプリ側でURL変更 • デバッグアプリを再起動 ⇨ 指定先のサーバーにアクセス設定専用ミニアプリ

Slide 41

Slide 41 text

41 • App Groups ○ アプリ間でデータ共有を行える仕組み ○ UserDefaultsを介し、URLの保持・取得を行いサーバーの接続先の動的差し替えを実現設定専用ミニアプリ

Slide 42

Slide 42 text

42 • TestFlightなどで配布できる仕組みを用意 ○ Bitriseに専用W/Fを用意 • iOS開発者以外の人もアプリの設定変更をできる設定専用ミニアプリ

Slide 43

Slide 43 text

43 • 良かった ○ アプリ側で都度修正, ビルドが不要なサーバー接続先の動的差し替えを実現 ○ SwiftUIで画面作成 • プロダクト側から完全に独立し依存問題が無い + UIもシンプルで良かったため活用設定専用ミニアプリ

Slide 44

Slide 44 text

44 • 課題/今後の展望 ○ 設定できる機能の拡充 • アバター向けデバッグメニュー • 端末, アカウント情報の確認 • Firebase RemoteConfigで利用しているflag設定設定専用ミニアプリ

Slide 45

Slide 45 text

45 ● 開発効率化を支える改善施策 • CI/CD環境の移行 • 設定専用ミニアプリ • マルチモジュール化 REALITY iOSアプリを支える開発効率化

Slide 46

Slide 46 text

• -2021.2 全てのソース: 1Application Target 46 マルチモジュール化

Slide 47

Slide 47 text

• -2021.2 全てのソース: 1Application Target ○ アーキテクチャ: MVVM, レイヤードアーキテクチャ ○ XcodeGen導入済み 47 マルチモジュール化

Slide 48

Slide 48 text

• -2021.2 全てのソース: 1Application Target ○ アーキテクチャ: MVVM, レイヤードアーキテクチャ ⇨ 責務の分離 ○ ○ XcodeGen導入済み ⇨ xcodeprojectファイルの競合問題の回避 ○ 48 マルチモジュール化

Slide 49

Slide 49 text

• 問題1: ビルド時間 ○ 差分ビルド不可, 修正の都度フルビルド ■ 機能が増える度にビルド時間も増長 ○ Unit Testの修正, 追加も一苦労 49 マルチモジュール化

Slide 50

Slide 50 text

• 問題2: 依存問題 ○ Bastard Injection • DIの仕組みの整備が必要 ○ 神(Singleton Manager)クラスの存在 • 疎結合な状態を作り出せていない ● 新しい技術の導入のし辛さ ● 変更した際の影響範囲の広さ etc. 50 マルチモジュール化

Slide 51

Slide 51 text

• 問題 ○ 依存問題 • Bastard Injection ● DIの仕組みの整備不足 • 神(Singleton Manager)クラスの存在 ● 疎結合な状態を作り出せていない ○ 新しい技術の導入のし辛さ ○ 変更した際の影響範囲の広さ etc. 51 マルチモジュール化モジュール分離＝マルチモジュール化

Slide 52

Slide 52 text

• 対応 ○ チームで定期的に話し合う時間を作る ○ モジュールの切り出し ○ DIの改善 52 マルチモジュール化

Slide 53

Slide 53 text

• 対応 ○ チームで定期的に話し合う時間を作る ○ モジュールの切り出し ○ DIの改善 53 マルチモジュール化

Slide 54

Slide 54 text

54 • 対応: チームで定期的に話し合う時間を作る ○ REALITY iOSのアーキテクチャについて話し合う時間を新たに用意 ⇨ あきべん。 ○ 週に1回・iOSメンバー全員が参加し実施 ○ 最近の主な話題 • マルチモジュール化, SwiftUIの導入, DI改善 etc. マルチモジュール化

Slide 55

Slide 55 text

55 • 対応: チームで定期的に話し合う時間を作る ○ 理由: チームの協力が必要不可欠 • 影響範囲が膨大 ● 目的 + 新しい設計ルールをチーム全員が理解, 協力しあう必要 ● 目的に沿っているか定期的に確認する時間が必要マルチモジュール化

Slide 56

Slide 56 text

56 • 対応: チームで定期的に話し合う時間を作る ○ マルチモジュール化について話したこと • モジュール構成 • 切り出す優先順位 • featureモジュール内の構成マルチモジュール化

Slide 57

Slide 57 text

• 対応 ○ チームで定期的に話し合う時間を作る ○ モジュールの切り出し ○ DIの改善 57 マルチモジュール化

Slide 58

Slide 58 text

58 マルチモジュール化

Slide 59

Slide 59 text

● Coreモジュール ○ エラー処理 ○ 既存のEntity ■ 新規分はfeatureモジュールに ○ 新規API Response ○ Infrastructure層のクラス 59 マルチモジュール化

Slide 60

Slide 60 text

• Coreモジュール ○ 多くのclassでprotocolによる抽象化 → 移行が容易 • Domain, Infrastructure層の移行は可視性の変更だけで対応ができた ○ 1ファイルに複数の定義があるor多くの依存の持っているオブジェクトの移行は大変 60 マルチモジュール化

Slide 61

Slide 61 text

• extension系モジュール ○ AppleFramework Extensions • UIKit, Foundation系 ○ ThirdPartyLib Extensions • RxSwift等のOSS系 ○ Reality Extensions • 上記2つのモジュールのWrapper • どのextension系モジュールをimportすべきかを意識しない作り 61 マルチモジュール化

Slide 62

Slide 62 text

• Loggerモジュール ○ ログ関連処理 • Firebase Analytics, Crashlytics, Performance • MetricsKit 62 マルチモジュール化

Slide 63

Slide 63 text

• RealityResourcesモジュール ○ Color Asset ○ Localization 63 マルチモジュール化

Slide 64

Slide 64 text

• RealityUIComponentsモジュール ○ モジュールを横断して利用するUI Component ■ Toast, Alert, Button, Cell等 64 マルチモジュール化

Slide 65

Slide 65 text

• RealityUIComponentsモジュール ○ IBLinter • Interface Builderファイルの静的検査 ● custom_moduleチェック ● その他: 制約重複, autolayout不正チェック ○ 既存のwarning数を減らした上で利用していきたい 65 マルチモジュール化

Slide 66

Slide 66 text

• Featureモジュール 66 マルチモジュール化

Slide 67

Slide 67 text

• Featureモジュール ○ 機能単位のミニアプリを作成 ○ 必要最低限の依存解決でビルド実行 • ビルド時間平均9秒 ● ビルド時間の大幅な改善 • プレビューサイクルの大幅な改善 ○ 画面遷移も通常の導線を跨ぐ必要無し 67 マルチモジュール化

Slide 68

Slide 68 text

• 対応 ○ チームで定期的に話し合う時間を作る ○ モジュールの切り出し ○ DIの改善 68 マルチモジュール化

Slide 69

Slide 69 text

• 対応: DI改善 ○ uber/needleをDIシステムに採用 • 理由 ● 依存解決コードを自動生成 ● 登場人物が少ない ● 安全で無い依存注入はビルドエラーで変数名, 型, 階層を指摘 69 マルチモジュール化

Slide 70

Slide 70 text

70 マルチモジュール化

Slide 71

Slide 71 text

71 マルチモジュール化

Slide 72

Slide 72 text

72 マルチモジュール化

Slide 73

Slide 73 text

73 マルチモジュール化

Slide 74

Slide 74 text

74 マルチモジュール化

Slide 75

Slide 75 text

• 対応: DI改善 ○ アプリ起動時〜ログイン画面まで導入済 • 詳細はnoteの記事をご覧ください 75 マルチモジュール化

Slide 76

Slide 76 text

• 良かった点 ○ チームで定期的に話し合う時間を作る • 目的や方針の認識確認をする時間が取れた 76 マルチモジュール化

Slide 77

Slide 77 text

• 良かった点 ○ チームで定期的に話し合う時間を作る • 目的や方針の認識確認をする時間が取れた ● ex) 移行対象のファイル 77 マルチモジュール化

Slide 78

Slide 78 text

• 良かった点 ○ モジュール切り出し • 多くのclassでprotocolによる抽象化 ● Domain, Infrastructure層の移行が可視性の変更だけで対応できた • Unit Testも充実していたため移行時の心理的安全性も高かった 78 マルチモジュール化

Slide 79

Slide 79 text

• 良かった点 ○ モジュール切り出し • featureモジュール ● ミニアプリの作成 ○ プレビューサイクルの大幅な改善 79 マルチモジュール化

Slide 80

Slide 80 text

• 課題/今後の展望 ○ featureモジュールの拡充 • 既存機能との依存関係を持たない部分のみ実現 • 神クラスによる依存問題解決に取り組みつつ、 featureモジュールを拡充していきたい 80 マルチモジュール化

Slide 81

Slide 81 text

• 課題/今後の展望 ○ モジュール形式 • framework → Swift Package ● project.pbxproj の変更に悩まされない ○ 将来的なXcodeGenからの脱却 ● link設定はdynamic ○ 起動時間短縮のためにstatic linkの検討も合わせて実施予定 81 マルチモジュール化

Slide 82

Slide 82 text

82 REALITY iOS 開発効率化の今後の展望

Slide 83

Slide 83 text

83 REALITY iOS 開発効率化の今後の展望

Slide 84

Slide 84 text

84 REALITY iOS 開発効率化の今後の展望

Slide 85

Slide 85 text

85 REALITY iOS 開発効率化の今後の展望

Slide 86

Slide 86 text

• マルチモジュール化 ○ featureモジュールの拡充 • ミニアプリを使った開発効率化の改善 • モジュール形式にSwift Pacakgeを採用 ● 将来的なXcodeGenの脱却 86 REALITY iOS 開発効率化の今後の展望

Slide 87

Slide 87 text

• 通信速度改善を目指した取り組み ○ Protocol Buffers ○ スキーマ定義 • SV/Native Appでソースコードの自動生成 ● 実装, コミュニケーションコスト双方の削減 87 REALITY iOS 開発効率化の今後の展望

Slide 88

Slide 88 text

• SwiftUIを画面実装の選択肢に ○ 実装コストの削減 ○ プレビュー機能を活用したプレビューサイクルの改善 ○ iOS14以上をサポートバージョン • リストの実装などで恩恵を得られるのも良い選定ポイントになっている 88 REALITY iOS 開発効率化の今後の展望

Slide 89

Slide 89 text

89 REALITY iOS 開発効率化の今後の展望『複数人が並行で作業を効率よく進められる仕組み』に引き続き取り組み、開発効率化を高めていきたい