2021/03/31に行われました「自動運転の自動運転以外のこと（Web/SRE/AI教習所）」ミートアップの資料です｡ GitFlowで開発していたチームがどのようにトランクベース開発を取り入れていったかをご紹介します。

1. トランクベース開発を活用して
爆速に開発した話
Shota Sawada
Mar 31st, 2021
1

2. Shota SAWADA
Profile
* FMSの開発
* 認証認可基盤の開発
GitHub: @sawadashota
Twitter: @xioota
2

3. トランクベース開発とは
3

4. GitFlowのおさらい
4
feature、develop、master(main)ブランチと
役割を持ったブランチが複数あり、
基本的には決まった順序でマージしていく
図は「A successful Git branching model」より引用 https://nvie.com/posts/a-successful-git-branching-model/

5. トランクベース開発とは
小さな作業単位でtrunk（メインブラ
ンチ）にコミットを積んでいく開発手
法。GitFlowとよく比較される。
5
図は「Trunk Based Development」より引用 https://trunkbaseddevelopment.com/

6. Philosophy
6
Branches create distance between developers and we do not want that
— Frank Compagner, Guerrilla Games
“
”distance”が大きいほど以下の問題が生じやすい。
* 予期せぬ不具合を引き起こす
* 差分が大きくなりすぎてマージが難しい
* 他の開発者と作業内容が被る

7. 特徴
7
* Remoteブランチは基本的にtrunkと呼ばれる1ブランチ
* Release Ready
* No Code Freeze
* featureブランチは可能な限り小さく、生存期間は極端に短い

8. Practice
8
* ペアプロ (同期レビュー)
* 同期レビューイベント
* trunkに入れたらすぐにレビュー (非同期レビュー)
DO NOT: Pull Requestを作成してApproveされるまで待ってからMerge (非同期レビュー)
Quick Code Review
* 完成していない機能を環境ごとにOn/Offを切り替えるしくみ
Feature Flags

9. Metrics
9
* アクティブなブランチ数: 3つ以下が望ましい
* Code Freezeの期間: Code Freezeはないほうが望ましい
* trunkにマージする頻度: 1日1回以上
* Approveにかかる時間: ゼロに近いほどよい
https://cloud.google.com/solutions/devops/devops-tech-trunk-based-development/?hl=ja

10. トランクベース開発を実践するための前提
10
Trunkにコミットが積まれたら
CIなどでRelease Readyであることを
担保しなくてはならない
OSSには不向き
チームメンバーのスキルに差があったり、
教育的にコードレビューを行っている場合も不向き
MergeにApproveが不要
自動でビルド・テスト
ビルドやテストの時間が短い
trunkに入ったコードのレビュー文化・仕組み
細かくコミットを積んでいくため、
CIに時間がかかってしまう場合は不向き
レビューなしにtrunkにコミットを積んだ場合、
Trunkにコミットが入ったあとに
コードレビューをやっていく文化や仕組みが必要

11. どのように取り入れたか
11

12. もともとはGitFlow
12
featureをdevelopにマージする前に
レビューを受ける
* developに入ったら開発環境にデプロイ
* releaseに入ったらQA検証環境にデプロイ
* masterに入ったら本番環境にデプロイ
図は「A successful Git branching model」より引用 https://nvie.com/posts/a-successful-git-branching-model/

13. トランクベース開発を取り入れるモチベーション
13
レビューを待つのも、
依頼が来たときにすぐにレビューするのも負荷
レビューがスタックして自分が相手の仕事を遅延させ
るのも嫌
レビューを待ちたくなかった PRマージの心理的負荷を下げたかった
不具合が起きたときの影響範囲が大きいため、長い
時間かけて大きくなったブランチをマージするのは
精神的に負荷が高い。
また、巨大PRはレビュアーにも負荷が高い。

14. トランクベース開発とGitFlowのハイブリッド
14
feature
(short lived)
feature
(short lived)
feature
(short lived)
develop
(trunk)
release main
GitFlow
Trunk Based

15. ポイント
15
* developブランチをtrunkと見なす
* developからmainにかけては従来どおりGitFlowにすることでチーム横断的な仕組みに適用
チームに閉じた部分にのみトランクベース開発を適用

16. 工夫した点
16
レビューなしでマージして、後からレビューする
レビュー忘れを防止するためにPRが作成されたら
自動で InReview ラベルをつけ、
レビューしたらラベルをはずすか、
コメント確認が必要であることをラベルで表現
作業分担前にペアプロでアーキテクチャや
実装スタイルの認識を合わせる
作業分担前にペアプロで認識合わせ
PRにラベルをつけてレビュー忘れ防止
レイヤで作業分担
コンフリクトを気にしせずに開発するために
レイヤで作業分担

17. Metrics
17
* アクティブなブランチ数: 3つ以下が望ましい
* Code Freezeの期間: Code Freezeはないほうが望ましい
* trunkにマージする頻度: 1日1回以上
* Approveにかかる時間: ゼロに近いほどよい
https://cloud.google.com/solutions/devops/devops-tech-trunk-based-development/?hl=ja

18. Metrics
18
* アクティブなブランチ数: 3つ以下が望ましい
=> GitFlow部分を含めた全体で見れば x。トランクベース開発を取り入れた部分で言えば ○
* Code Freezeの期間: Code Freezeはないほうが望ましい
=> GitFlow部分はx。トランクベース開発を取り入れた部分で言えば ○。
* trunkにマージする頻度: 1日1回以上
=> 平均 6 PRs/day
* Approveにかかる時間: ゼロに近いほどよい
=> 判断に悩んだ部分は作業分担後もレビュー待ちPRは例外的にあったものの基本ゼロなので ○
https://cloud.google.com/solutions/devops/devops-tech-trunk-based-development/?hl=ja

19. Good
指摘を受けるうちにscopeが大きくなったり、
レビューを待つと思うと、「ついでにこれもいれちゃ
おう」となってしまうことがなかった。
また、小さい変更量で修正できるコードベースになり
やすいと感じた。
トランクベース開発と言えるのか
ブランチは1つにし、
trunkに入ったら本番リリースするところまでは
できておらず、これをトランクベース開発と
呼べるかは怪しい・・・
小さいPRをレビューを待たずにマージしていくこと
で、待ち時間や作業を止めてレビューするコンテキス
トスイッチ、コンフリクトしないように意識する必要
がなくなり、結果的に開発速度はあがった。（PR数
は3倍、PRあたりの行数は半減）
PRの肥大化が起こらなかった
開発速度があがった(気がする)
19
Bad

20. © 2021 Tier IV, Inc. 20