Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
REALITY iOSアプリを支える開発効率化
Search
gree_tech
PRO
November 11, 2021
Technology
0
310
REALITY iOSアプリを支える開発効率化
GREE Tech Conference 2021 で発表された資料です。
https://techcon.gree.jp/2021/session/Session-12
gree_tech
PRO
November 11, 2021
Tweet
Share
More Decks by gree_tech
See All by gree_tech
kustomizeをいい感じに使う方法
gree_tech
PRO
5
3.2k
スケーラビリティとコスト管理 Google Cloud Spanner 費用最適化の取り組み
gree_tech
PRO
0
940
「アナザーエデン 時空を超える猫」の5年前のログを引っ越してデータドリブンで事業運用プロセスを改善した話
gree_tech
PRO
0
660
Unity,PHP+Jenkins+GAS 多言語対応を意識させない開発を目指したシステム構築
gree_tech
PRO
0
1.2k
全社総会における「REALITY Spaces」の活用と、Addressableを用いたコンテンツ配信技術について
gree_tech
PRO
0
770
AWSのEKS環境でログ機能を構築/リリースしたお話
gree_tech
PRO
0
600
「ヘブンバーンズレッド」の大規模アップデートにおける国内及び翻訳QAの取り組み
gree_tech
PRO
0
720
アプリ「REALITY」の12言語対応プロセスの仕組みと品質向上の取り組み
gree_tech
PRO
0
1k
REALITYアプリのメンテナンスなしでの機能リリースを実現する、Istio導入とB/Gデプロイ実現の取り組み
gree_tech
PRO
1
840
Other Decks in Technology
See All in Technology
RAGの性能を評価しよう
kurahara
1
270
VS CodeでF1〜12キーつかってますか? / Do you use the F1-12 keys in VS Code?
74th
1
260
SQLによるオブザーバビリティの進化とClickHouseの実力
mikimatsumoto
0
150
【shownet.conf_】放送局とShowNetが共創する、未来の放送システム ~Media over IP 特別企画の裏側~
shownet
PRO
0
260
ドメインと向き合う - 旅行予約編
hidenorigoto
4
510
CVE alive
ennael
PRO
0
360
Authenticator のエミュレーションによる パスキーのログインテスト/nikkei-tech-talk-25
nikkei_engineer_recruiting
0
140
普通の Web エンジニアのための様相論理入門 #yapcjapan / YAPC Hakodate 2024
ytaka23
1
170
【swonet.conf_】NOCメンバーが語るSTMの実態!! ~ShowNetから若者への贈り物~
shownet
PRO
0
220
【shownet.conf_】3Dアプローチで守るセキュリティ
shownet
PRO
0
270
KDD2024参加報告
cyberagentdevelopers
PRO
0
190
Assisted reorganization of data structures
ennael
PRO
0
210
Featured
See All Featured
Automating Front-end Workflow
addyosmani
1365
200k
The Invisible Side of Design
smashingmag
297
50k
WebSockets: Embracing the real-time Web
robhawkes
59
7.3k
What’s in a name? Adding method to the madness
productmarketing
PRO
22
3.1k
Product Roadmaps are Hard
iamctodd
PRO
48
10k
Bootstrapping a Software Product
garrettdimon
PRO
304
110k
Atom: Resistance is Futile
akmur
261
25k
A Philosophy of Restraint
colly
202
16k
A better future with KSS
kneath
235
17k
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
230
17k
Principles of Awesome APIs and How to Build Them.
keavy
126
17k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
1
230
Transcript
REALITY iOSアプリを支える 開発効率化 REALITY株式会社 エンジニア かむい
2 自己紹介 • かむい/@kamui_project • 2020.08- REALITY Inc. • VTuber大好きおじさん
3 アジェンダ • 開発効率化を支える改善施策 • CI/CD環境の移行 • 設定専用ミニアプリ • マルチモジュール化
4 アジェンダ • 開発効率化を支える改善施策 • CI/CD環境の移行 • 設定専用ミニアプリ • マルチモジュール化
その前に
5 開発効率化の目的
6 REALITY • 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 ◦ 新機能開発はエンジニア全員原則STOP 21 開発効率化を支える改善施策
• 品質改善プロジェクト ◦ 中長期規模の品質改善の取り組み • 複数テーマを決め、各々チームを作って対応 ◦ 新機能開発とは別にまとまった時間を用意 • 時間は施策規模感によりけり
• 施策によって対応時期を分ける必要があれば調整 22 開発効率化を支える改善施策
23 • 開発効率化を支える改善施策 • CI/CD環境の移行 • 設定専用ミニアプリ • マルチモジュール化 REALITY
iOSアプリを支える開発効率化
24 • - 2020.11 Jenkins CI/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 Flight App作成 CI/CD環境の移行
32 • Slack Botを使いdeployする仕組み CI/CD環境の移行
33 • 良かった点 ◦ iOS開発における物理出社の懸念を取り除くことが出 来た ◦ Jenkinsを稼働させていたW/F数減 • iMac
Proの負担を軽減 CI/CD環境の移行
• 課題/今後の展望 ◦ Bitriseを今後も使っていくか: △ • 💰の問題: 従量課金制 ◦ 必要であれば柔軟にCI/CD環境を移行できる仕組みを
考慮しておくことが寛容 • ex) Github Actions 34 CI/CD環境の移行
• 課題/今後の展望 ◦ Bitriseを今後も使っていくか: △ • 💰の問題: 従量課金制 ◦ 必要であれば柔軟にCI/CD環境を移行できる仕組みを
考慮しておくことが寛容 • ex) Github Actions 35 CI/CD環境の移行 そのために何ができるか
• ex) Credentialな情報をどこに格納するか ◦ 現在: Bitrise Secrets • 1つのCI/CDサービスに依存してる仕組み ◦
今後: 外部のストレージサービスを利用 • ex) GCP Secret Manager 36 CI/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 Target 46 マルチモジュール化
• -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 •
MetricsKit 62 マルチモジュール化
• RealityResourcesモジュール ◦ Color Asset ◦ Localization 63 マルチモジュール化
• 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 マルチモジュール化
82 REALITY iOS 開発効率化の今後の展望
83 REALITY iOS 開発効率化の今後の展望
84 REALITY iOS 開発効率化の今後の展望
85 REALITY iOS 開発効率化の今後の展望
• マルチモジュール化 ◦ featureモジュールの拡充 • ミニアプリを使った開発効率化の改善 • モジュール形式にSwift Pacakgeを採用 •
将来的なXcodeGenの脱却 86 REALITY iOS 開発効率化の今後の展望
• 通信速度改善を目指した取り組み ◦ Protocol Buffers ◦ スキーマ定義 • SV/Native Appでソースコードの自動生成
• 実装, コミュニケーションコスト双方の削減 87 REALITY iOS 開発効率化の今後の展望
• SwiftUIを画面実装の選択肢に ◦ 実装コストの削減 ◦ プレビュー機能を活用したプレビューサイクルの改善 ◦ iOS14以上をサポートバージョン • リストの実装などで恩恵を得られるのも良い選定
ポイントになっている 88 REALITY iOS 開発効率化の今後の展望
89 REALITY iOS 開発効率化の今後の展望 『複数人が並行で作業を効率よく進められる仕組み』 に引き続き取り組み、開発効率化を高めていきたい
90 note meety We’re Hiring!
91