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