Downloaded 24 times
More Related Content
![[AKIBA.AWS] VPN接続とルーティングの基礎](https://cdn.slidesharecdn.com/ss_thumbnails/akibaaws6vpn-180510092054-thumbnail.jpg?width=640&height=640&fit=bounds)
Similar to AbemaTV モバイルアプリの開発体制と開発プロセスの話
AbemaTV モバイルアプリの開発体制と開発プロセスの話
- 1. AbemaTV モバイルアプリの開発体制と 開発プロセスの話 Yuji Hato AbemaTV DEVELOPERCONFERENCE 2017
- 2. Yuji Hato CyberAgent, Inc./ AbemaTV, Inc. dekatotoro @dekatotoro Contributed services About me
- 3.
- 4.
- 5.
- 6. 開発体制 Server Web iOSAndroidDesignDirector QA Board
- 7. 開発体制 Server Web iOSAndroidDesignDirector QA Board
- 8.
- 9.
- 10.
- 11.
- 12. iOSチーム ビデオ グロース 本質改善テレビデバイス その他案件 A, B, C..
- 13. AbemaTV 対応デバイス PC iPhone /iPad Android / タブレット Apple TV AndroidTV / Amazon Fire TV Google Cast
- 14. AbemaTV 対応デバイス PC iPhone /iPad Android / タブレット Apple TV AndroidTV / Amazon Fire TV Google Cast iOSチーム
- 15.
- 16. Codebase ios … iOSアプリ tvos… tvOSアプリ api … API周りのモジュール protobuf-swift … proto swift cmdshelf-ios … script郡 etc.. (mock, tool, sample) repositories
- 17.
- 18.
- 19.
- 20.
- 21.
- 22.
- 23.
- 24.
- 25.
- 26.
- 27.
- 28. 開発 QA 1週間 1週間 開発 開発開発 QA QA 申請 申請 申請申請 QA 開発フロー
- 29. 開発 QA 1週間 1週間 開発 開発開発 QA QA 申請 申請 申請申請 QA 開発フロー
- 30.
- 31.
- 32. QA 1週間 1週間 QA QA 申請申請 申請申請 QA 開発 開発 開発 開発フロー
- 33. QA 1週間 1週間 QA QA 申請申請 申請申請 QA 開発 開発 開発 長い開発 開発フロー
- 34. QA 1週間 1週間 QA QA 申請申請 申請申請 QA 開発 開発 開発 開発フロー フライング開発 できる人だけ
- 35.
- 36.
- 37.
- 38.
- 39. タスクの見積もり ストーリーポイント 1 … 軽微なもの 2… 0.5スプリント 3 … １スプリント、またはそれ以上
- 40. ストーリーポイント 1 … 軽微なもの 2… 0.5スプリント おおざっぱ !? タスクの見積もり 3 … １スプリント、またはそれ以上
- 41.
- 42. 優先度定義 優先度は5段階 S, A,B C, D スプリント期間に開発完了 / テスト / リリース必 須。定常リリース日に間に合わなければリリース 日を遅らせる判断もする スプリント期間に開発完了 / テスト / リリース必 須ではない。開発着手はするものの、開発締め日 に間に合わなければ次回リリースに回す
- 43.
- 44.
- 45.
- 46.
- 47.
- 48.
- 49.
- 50.
- 51.
- 52.
- 53.
- 54.
- 55. Pull Requests pull request抜粋 活発なレビュー文化 開発スタイル
- 56.
- 57. テスト Executed 2009 tests,with 0 failures (0 unexpected) in 20.517 (21.345) seconds テスト極力書く！ 2017/10/19 開発スタイル
- 58.
- 59.
- 60. ブランチ戦略 基本はGitHub Flow 各自トピックブランチをmaster /qaから 作って作業 開発用のmasterブランチとQA用のqaブランチ
- 61.
- 62. ブランチ戦略 master 2.3.0 開発master 2.4.0 開発 tag 2.2.0 申請 qa master qa 2.2.0 QA qa 2.3.0 QA スプリント2.3.0 qa スプリント2.2.0 スプリント2.4.0 tag 2.3.0 申請 merge merge
- 63. master 2.3.0 開発master 2.4.0 開発 tag 2.2.0 申請 qa master qa 2.2.0 QA qa 2.3.0 QA スプリント2.3.0 qa スプリント2.2.0 スプリント2.4.0 tag 2.3.0 申請 merge merge ブランチ戦略 スプリント2.3.0
- 64. master 2.3.0 開発master 2.4.0 開発 tag 2.2.0 申請 qa master qa 2.2.0 QA qa 2.3.0 QA スプリント2.3.0 qa スプリント2.2.0 スプリント2.4.0 tag 2.3.0 申請 merge merge ブランチ戦略 2.3.0 開発期間中 はmaster
- 65. master 2.3.0 開発master 2.4.0 開発 tag 2.2.0 申請 qa master qa 2.2.0 QA qa 2.3.0 QA スプリント2.3.0 qa スプリント2.2.0 スプリント2.4.0 tag 2.3.0 申請 merge merge ブランチ戦略 2.3.0 QA期間中 はqa
- 66. master 2.3.0 開発master 2.4.0 開発 tag 2.2.0 申請 qa master qa 2.2.0 QA qa 2.3.0 QA スプリント2.3.0 qa スプリント2.2.0 スプリント2.4.0 tag 2.3.0 申請 merge merge ブランチ戦略 2.3.0 QA期間中の masterは2.4.0開発 (できる人だけ)
- 67. master 2.3.0 開発master 2.4.0 開発 tag 2.2.0 申請 qa master qa 2.2.0 QA qa 2.3.0 QA スプリント2.3.0 qa スプリント2.2.0 スプリント2.4.0 tag 2.3.0 申請 merge merge ブランチ戦略 2.3.0申請後 qa -> masterにmerge (適時mergeしてる)
- 68. ブランチ戦略 master 2.3.0 開発master 2.4.0 開発 tag 2.2.0 申請 qa master qa 2.2.0 QA qa 2.3.0 QA スプリント2.3.0 qa スプリント2.2.0 スプリント2.4.0 tag 2.3.0 申請 merge merge
- 69.
- 70.
- 71.
- 72.
- 73.
- 74.
- 75.
- 76.
- 77.
- 78.
- 79.
- 80.
- 81.
- 82.
- 83.
- 84.
- 85.
- 86.
- 87.
- 88.
- 89.
- 90.
- 91.
- 92.
- 93.
- 94.
- 95.
- 96.
- 97.
- 98.
Editor's Notes
- #4 では早速開発体制についてですが、
- #5 ということで早速開発体制についてですが、
- #6 現在AbemaTVの開発局は約50名程度います
- #7 えー図にするとこのような感じで、左からDirector, Server Design, Web, iOS, Android, QAといたチームに分かれていて、それぞれのチームの代表でBoardメンバーが構成されています.
- #8 今日はこの中で、iOSチームについての開発体制や開発スタイルについてお話したいと思います。
- #9 まずiOSチームの中でもチームが分かれていて ビデオチーム、グロースチーム、本質改善チーム、テレビデバイスチームと大きく4つに分かれていて、その他にどれに属さない案件、プロジェクトなどがあったりします。
- #10 iOSチームですが、
- #11 現在10名体制で開発しています。 立ち上げ初期は４名程度だったのでだいぶ大きなチームになりました。
- #12 はい、みんなに顔出しOKもらったので載せておきますw
- #13 で、具体的には、先程お話したビデオ、グロース、本質改善、テレビデバイスチームはこのような形で分かれていて、その他の案件はケースバイケースでその時の状況で調整して対応しています。
- #14 AbemaTVの対応デバイスはPC, iPhone/iPad, Android/タブレット、 AppleTV, AndroidTV, Google Castがあります。
- #15 この中でiOSチームはiPhone, iPad, AppleTV, あとGoogle Castはテレビ側のrecieverとクライアント側のsenderがありますが、sender側が担当範囲になります。
- #16 iOSチームが管理しているcodebaseですが、
- #17 代表的なレポジトリはiosとtvosの２つになります あとは共通のapiモジュールや あっprotocolBuffer使っているのですが、protoのswiftのレポジトリ 共通のscript郡のcmdshelfレポジトリなどがあります
- #18 これはcodeのfile数や行数を出したものですが
- #19 iosで約9万行、tvosで27000行、apiで3800行くらいですね
- #20 こちらはiosレポジトリのGitHubのinsightsになります
- #21 iosのレポジトリだと、これは9月19~ 10月19日の1ヶ月で162個のpull requestがマージされていて、営業で1日平均すると、、だいたい7~8個のpull requestがマージされています、 ちなみに一番右の全然commitしてないのはデザイナーで画像差し替えとか文言変更はデザイナーが対応してくれたりします
- #22 こちらはtvOSですが、おもに２人で開発していて
- #23 tvosのレポジトリだと、57個のpull requestが1ヶ月でマージされていて、営業で1日平均すると、、だいたい2~3個のpull requestがマージされています
- #24 こちらは共通のapiモジュールのレポジトリですが
- #25 こちらもちょくちょく変更がはいります
- #26 何が言いたいかといいますと、まぁみんな仕事していますとw もとい毎日大量のコードが変更されていることがわかると思います
- #27 では、そういった開発をしているフローはどうなっているかというと、
- #28 こちらの図のような感じで、基本はスクラム開発でsprintを２週間に区切って開発しています。
- #29 もうちょっと細かくした図ですが、これは少し前に実践していたフローですが、 開発を二週間、QAを１週間で2週間ごとの申請でやっていました。 ただこれでやっていると問題がありまして、
- #30 ここの期間ですね。
- #31 開発とQA期間の重複がつらいですと。 QA中にバグ対応などがお主に発生すると、次のsprintへの影響がもろにでてしまうのでこれは無理があるということで、
- #32 改善しました。
- #33 開発期間1週間、QA期間1週間という定義でやることにしました。 今のところこれでスムーズにいっています。
- #34 長い開発はこのような形でsprintを跨いだ開発になります
- #35 厳密に１週間/１週間にはならないときも、もちろんあるので、QA期間中から開発をはじめているものもあります。計画ミーティングごとに何をやるか決めますが、ある程度先のsprintの開発まで決めているのでこういった調整が容易になっています。
- #36 ではそもそもタスクはどうやって発生しているのかということですが、
- #37 パターン1として、、、、、いわゆるトップダウン的なものですね
- #38 パターン2は、、、、、といったボトムアップでタスク化することも多々あります。
- #39 ではどうやってタスクを見積もっているかということですが、
- #40 一応タスクにストーリーポイントを付けています。1ポイントが軽微なもの、2ポイントが0.5スプリント、3ポイントが1スプリント、またはそれ以上といった定義しかしていません
- #41 ものすごいおおざっぱですねw この数値の付け方はスクラム開発だと変な定義だと思いますが、 AbemaTVは事業の流れによって案件の優先度がけっこう変わるので、ガチガチにポイントつけてSprintを回すのは向いてなくて、一人ひとりが今どれくらい案件を抱えていて、どのくらい重い開発をしているかを見える化する程度にしています。 ただここももう少しちゃんとポイント定義して回せるようにしていきたいと考えています
- #42 タスクの優先度定義ですが、
- #43 チケットを見ただけでこれは今回マストで入れないといけないのか、次に回してもいいのかエンジニアが判断できるようにしています。こういった共通言語の定義があることで、ディレクターなどとの会話がスムーズにいくといった利点もあります。
- #44 あと会議体ですが、
- #45 大きく4つありまして、スプリント計画を行うスプリント計画ミーティング、スプリントの振り返りを行うスプリントレビュー、メンバー各自の案件ごとのミーティングとiOSチームの週一の定例をやっています。毎日の行うようなデイリースクラムはやっていません
- #46 あと使っているツールの紹介します
- #47 使っているツールですが、いわゆる一般的なものでチャットツールのSlack、チケット管理にJIRA, ドキュメントツールにConfluenceとesa、ソースコード管理にGitHub、CI用にBitriseと自動化用にJenkinsとcmdshelfなどを使っています。
- #48 cmdshlefはオリジナルなので知らない人も多いかと思うので少し紹介すると
- #49 リモートリポジトリの実行可能ファイルをローカルファイルのように統合して扱えるようにするもので、iOSチームのトッシーさんという方がつくっていてSwift製です
- #50 こちら実際の例になります。
- #51 最初の方でお話しましたが、iOSチームで管理している共通script置き場のcmdshelf-iosというレポジトリがあります
- #52 cmdshelfをinstallしてこのレポジトリをaddして、cmdshelf listを実行すると実行できるコマンド郡が表示されるようになります
- #53 listで表示されたものをcmdshelf runで実行できるといった形で、リモートのレポジトリのscript郡を手軽に使えてけっこう便利なものになります。
- #54 はい、次に開発スタイルですが、
- #55 こちらはContributing.mdのPullRequestsについての抜粋ですが、、、 といったルールも定義しています
- #56 これはPull Requestsのリストの抜粋ですが、ちょっと多いとか少ないとかの平均はわかりませんが、自分の経験上、けっこう活発なレビュー文化だと思います。
- #57 こちらはコーディング規約でGoodな書き方とBadの書き方というのを明示して、なるべくチーム内でコードの統一性を出すようにしています。
- #58 こちらはテストの実行結果ですが、現在2009ケースのテストがあり、極力テストは書くという方針ですすめています。ViewやViewControllerのテストはデザインや仕様も頻繁に変わる現状だとコストが大きいのと、ViewとModelを分離する設計にしているので、Viewのテストは書かなくてよい、Model層やロジックはテスト書くようにしましょうといった方針にしています。
- #59 右の図はiOSの週一定例のシートですが、急ぎでないものは各自思いついた時に議題を入れてもらって、定例で結論を出してアクションしていくといったやり方をしています。あとはGitHubやSlack上での議論から開発ルールを更新していっています。
- #60 次にブランチ戦略についてお話します
- #62 シンプルにこのような形になります。masterブランチがあってQA期間中はqaブランチを使うといったやり方にしています。
- #63 これにsprintの図を当てはめるとこのような感じです 左が仮でスプリント2.2.0、真ん中がスプリント2.3.0、右が2.4.0になります
- #64 真ん中のスプリント2.3.0を例に見てみますと
- #65 2.3.0の開発期間中はmasterブランチからトピックブランチを切ってmsterにプルリクしてmasterにマージします
- #66 2.3.0のQA期間中はqaブランチからトピックブランチを切ってプルリクエスト、qaブランチにマージします
- #67 2.3.0QA期間中のmasterブランチは2.4.0（次のversion)の開発ブランチになります
- #68 2.3.0の申請が終わったらqaブランチをmasterにマージします。 ここは申請というよりは適時マージしているイメージになります
- #69 このブランチ戦略の良いところとしては、プルリクエストのmergeができないということがあまり発生しないということと、基本はGitHubフローでシンプルでわかりやすい点です。スクラム開発のsprintサイクルにうまくはまるのではないかと思います。
- #70 えー、Beta配信ということで、テスト用アプリの配信の自動化とフローについてです
- #71 図のような感じになります
- #72 まず Developerがプルリクエストします。
- #73 レビューを通ってmergeされると、bitriseがhookでjobを起動します
- #74 対象ブランチは先程お話したmasterとqaを対象にしていて、Crashlyticsにuploadして、TesterやDesigner、Directorなどがすぐに確認できるようなっています。 あとはmasterとqa以外にqa-xxxxといった名前でブランチを上げると配信するようにしていて、特別なversionで何か確認してもらいたい時などにも配信できるようにしています
- #75 あとはQA期間中はTestFlightにも配信して、本番と同じ状態で確認できるようにしています
- #76 はい、あとはSlackの通知もいくつか自動化しているものを紹介します
- #77 いくつかピックアップしたいと思います
- #78 左上はCocoaPodsのライブラリのアップデートある場合に〜通知しているものです
- #79 これは最新のqaビルドが配信されたよ〜といったお知らせで
- #80 Crashがけっこう起きてるよ〜といったお知らせ、
- #81 これは自前のbotですが、レビューがしばらくされてないプルリクエストがあるよとお知らせしているものです。
- #82 あとはp12の証明書が切れそうだよ〜とか
- #83 App Storeのレビュー評価
- #84 iOS11のbeta10でたよ〜といったAppleのRSSなどをSlackに通知しています。
- #85 はい、最後にQAの効率化についての取り組みについてです
- #86 機能が多くなり複雑になってくると、QAの時間も比例して大きくなってきてしまいます。その効率化にも取り組んでいて、デバッグメニューを容易しています 現状のデバッグメニューの機能についていくつかピックアップすると
- #95 その他としてカンファレンスへの登壇や、チーム内でのランチ勉強会などを行うことによって直接だけでなく間接的に知見の共有になったりしています
- #97 はい、まとめです。AbemaTVは事業的に先を見据えたサービスなので、その場しのぎで開発していると長期的な開発のどこかで破綻してしまう可能性もあると思います。なのでAbemaTVのモバイル開発においても長期的な視点で、開発スピードとアプリの安定性、コードの品質を保った継続的な開発ができるように意欲的に取り組んでいます。 簡単になりますがまとめということで、発表を終わりにしたいと思います