トランクベース開発を活用して爆速に開発した話
5.8K Views
April 01, 21
スライド概要
2021/03/31に行われました「自動運転の自動運転以外のこと（Web/SRE/AI教習所）」ミートアップの資料です｡
GitFlowで開発していたチームがどのようにトランクベース開発を取り入れていったかをご紹介します。
関連スライド
各ページのテキスト
トランクベース開発を活用して 爆速に開発した話 Shota Sawada Mar 31st, 2021 1
Profile Shota SAWADA * FMSの開発 * 認証認可基盤の開発 GitHub: @sawadashota Twitter: @xioota 2
トランクベース開発とは 3
GitFlowのおさらい feature、develop、master(main)ブランチと 役割を持ったブランチが複数あり、 基本的には決まった順序でマージしていく 図 は 「 A successful Git branching model」 よ り 引 用 https://nvie.com/posts/a-successful-git-branching-model/ 4
トランクベース開発とは 小さな作業単位でtrunk（メインブラ ンチ）にコミットを積んでいく開発手 法。GitFlowとよく比較される。 図 は 「 Trunk Based Development」 よ り 引 用 https://trunkbaseddevelopment.com/ 5
Philosophy “ Branches create distance between developers and we do not want that — Frank Compagner, Guerrilla Games ”distance”が大きいほど以下の問題が生じやすい。 * 予期せぬ不具合を引き起こす * 差分が大きくなりすぎてマージが難しい * 他の開発者と作業内容が被る 6
特徴 * Remoteブランチは基本的にtrunkと呼ばれる1ブランチ * Release Ready * No Code Freeze * featureブランチは可能な限り小さく、生存期間は極端に短い 7
Practice Quick Code Review * ペアプロ (同期レビュー) * 同期レビューイベント * trunkに入れたらすぐにレビュー (非同期レビュー) DO NOT: Pull Requestを作成してApproveされるまで待ってからMerge (非同期レビュー) Feature Flags * 完成していない機能を環境ごとにOn/Offを切り替えるしくみ 8
Metrics * アクティブなブランチ数: 3つ以下が望ましい * Code Freezeの期間: Code Freezeはないほうが望ましい * trunkにマージする頻度: 1日1回以上 * Approveにかかる時間: ゼロに近いほどよい https://cloud.google.com/solutions/devops/devops-tech-trunk-based-development/?hl=ja 9
トランクベース開発を実践するための前提 MergeにApproveが不要 ビルドやテストの時間が短い OSSには不向き チームメンバーのスキルに差があったり、 教育的にコードレビューを行っている場合も不向き 細かくコミットを積んでいくため、 CIに時間がかかってしまう場合は不向き 自動でビルド・テスト trunkに入ったコードのレビュー文化・仕組み Trunkにコミットが積まれたら CIなどでRelease Readyであることを 担保しなくてはならない レビューなしにtrunkにコミットを積んだ場合、 Trunkにコミットが入ったあとに コードレビューをやっていく文化や仕組みが必要 10
どのように取り入れたか 11
もともとはGitFlow featureをdevelopにマージする前に レビューを受ける * developに入ったら開発環境にデプロイ * releaseに入ったらQA検証環境にデプロイ * masterに入ったら本番環境にデプロイ 図 は 「 A successful Git branching model」 よ り 引 用 https://nvie.com/posts/a-successful-git-branching-model/ 12
トランクベース開発を取り入れるモチベーション レビューを待ちたくなかった PRマージの心理的負荷を下げたかった レビューを待つのも、 依頼が来たときにすぐにレビューするのも負荷 レビューがスタックして自分が相手の仕事を遅延させ るのも嫌 不具合が起きたときの影響範囲が大きいため、長い 時間かけて大きくなったブランチをマージするのは 精神的に負荷が高い。 また、巨大PRはレビュアーにも負荷が高い。 13
トランクベース開発とGitFlowのハイブリッド Trunk Based GitFlow feature (short lived) feature (short lived) develop (trunk) release main feature (short lived) 14
ポイント チームに閉じた部分にのみトランクベース開発を適用 * developブランチをtrunkと見なす * developからmainにかけては従来どおりGitFlowにすることでチーム横断的な仕組みに適用 15
工夫した点 作業分担前にペアプロで認識合わせ レイヤで作業分担 作業分担前にペアプロでアーキテクチャや 実装スタイルの認識を合わせる コンフリクトを気にしせずに開発するために レイヤで作業分担 PRにラベルをつけてレビュー忘れ防止 レビューなしでマージして、後からレビューする レビュー忘れを防止するためにPRが作成されたら 自動で InReview ラベルをつけ、 レビューしたらラベルをはずすか、 コメント確認が必要であることをラベルで表現 16
Metrics * アクティブなブランチ数: 3つ以下が望ましい * Code Freezeの期間: Code Freezeはないほうが望ましい * trunkにマージする頻度: 1日1回以上 * Approveにかかる時間: ゼロに近いほどよい https://cloud.google.com/solutions/devops/devops-tech-trunk-based-development/?hl=ja 17
Metrics * アクティブなブランチ数: 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 18
Good Bad PRの肥大化が起こらなかった 指摘を受けるうちにscopeが大きくなったり、 レビューを待つと思うと、「ついでにこれもいれちゃ おう」となってしまうことがなかった。 また、小さい変更量で修正できるコードベースになり やすいと感じた。 トランクベース開発と言えるのか ブランチは1つにし、 trunkに入ったら本番リリースするところまでは できておらず、これをトランクベース開発と 呼べるかは怪しい・・・ 開発速度があがった(気がする) 小さいPRをレビューを待たずにマージしていくこと で、待ち時間や作業を止めてレビューするコンテキス トスイッチ、コンフリクトしないように意識する必要 がなくなり、結果的に開発速度はあがった。（PR数 は3倍、PRあたりの行数は半減） 19
© 2021 Tier IV, Inc. 20