トランクベース開発のすすめ

Transcript

1. トランクベース開発のすすめ
   Taiga Sakaguchi
   1
   

   View Slide

2. Taiga
   教員→Web
   エンジニア
   歴3
   年
   バックエンドエンジニア
   都内メガベンチャーに勤務
   2
   

   View Slide

3. みなさん爆速開発できていますか？
   3
   

   View Slide

4. テーマ
   :
   『変更点を小さくする』
   4
   

   View Slide

5. こんな辛みありませんか？
   PR
   の差分が大きくコンフリクトしてしまう
   変更点が多くレビューアーの負担が大きい
   main
   ブランチへのマージの変更が大きくリリースが怖い
   ブランチのパターンが複雑で運用が辛い
   バグが起きた際の原因特定に時間がかかってしまう
   レビュー待ちが長い
   5
   

   View Slide

6. そう、「トランクベース開発」ならね
   6
   

   View Slide

7. トランクベース開発とは、変更点を小
   さくすることで生産性を高める手法
   7
   

   View Slide

8. 機能ブランチを使った手法
   機能ごとにブランチを作成し実装完了後トランク
   (*1)
   にマージする手
   法
   例えば、
   git-flow
   github-flow
   実装完了しマージできるまでに数日から数週間かかる
   *(1)
   トランクとは、いわゆるmain
   ブランチのことです
   8
   

   View Slide

9. 機能ブランチの例
   出典: https://trunkbaseddevelopment.com
   9
   

   View Slide

10. トランクベース開発
    小さな単位に分割して実装し、1
    日に1
    回以上トランクにマージする
    手法
    実装は数時間から数日以内で完了し個々の変更を頻繁にトランクに
    マージする。
    1
    日に複数回のリリース
    10
    

    View Slide

11. トランクベース開発のブランチ
    11
    

    View Slide

12. Four Keys
    ソフトウェア開発チームのパフォーマンスを示す4
    つの指標
    デプロイの頻度
    組織による正常な本番環境へのリリースの頻度
    変更のリードタイム
    commit
    から本番環境稼働までの所要時間
    変更障害率
    デプロイが原因で本番環境で障害が発生する割合（%
    ）
    サービス復元時間
    組織が本番環境での障害から回復するのにかかる時間 12
    

    View Slide

13. 出典: https://cloud.google.com/blog/ja/products/gcp/using-the-four-keys-to-measure-your-devops-performance
    13
    

    View Slide

14. 実現するためのポイント
    コードレビュー
    プロセスを簡略化
    同期的なレビュー
    コーディングルール
    テスト＆ビルド
    自動テストの実行
    ビルドを迅速に行う
    14
    

    View Slide

15. トランクベース開発の
    Pros & Cons
    Pros
    新機能をいち早く提供できる
    レビュアーの負担が軽くなる
    コンフリクトを抑えられる
    コードフリーズのような統合期
    間が不要
    バグの原因を特定しやすい
    Cons
    デプロイ可能な単位に作業を分
    割する必要がある
    CI/CD
    環境の整備が必要（自動
    テスト・ビルド）
    15
    

    View Slide

16. 生産性
    vs.
    信頼性
    16
    

    View Slide

17. 生産性
    with
    信頼性
    17
    

    View Slide

18. とは言っても本番に出したくないときもある
    18
    

    View Slide

19. フィーチャーフラグ
    コードを書き換えることなく、動的に機能のON/OFF
    を切り替えシス
    テムの振る舞いを変更することができる手法
    if featureFlg {
    // Do something
    } else {
    // Do something else
    }
    19
    

    View Slide

20. トランクベース開発が向いていないケ
    ース
    明確にバージョンごとにリリースしたい場合
    20
    

    View Slide

21. おまけ
    21
    

    View Slide

22. Progressive Delivery
    Canary Release
    に加えて、SLO
    などのメトリクスを閾値として分析
    しデプロイする手法
    分析に通らなければ自動でロールバック
    22
    

    View Slide

23. 出典: https://static.sched.com/hosted_files/kccncna19/f2/Progressive Delivery %26 Argo Rollouts.pdf
    23
    

    View Slide

24. 出典: https://static.sched.com/hosted_files/kccncna19/f2/Progressive Delivery %26 Argo Rollouts.pdf
    24
    

    View Slide

25. Four Keys
    デプロイの頻度
    組織による正常な本番環境へのリリースの頻度
    変更のリードタイム
    commit
    から本番環境稼働までの所要時間
    変更障害率
    デプロイが原因で本番環境で障害が発生する割合（%
    ）
    サービス復元時間
    組織が本番環境での障害から回復するのにかかる時間
    25
    

    View Slide

26. 出典: https://cloud.google.com/blog/ja/products/gcp/using-the-four-keys-to-measure-your-devops-performance
    26
    

    View Slide

27. 参考
    https://cloud.google.com/architecture/devops/devops-tech-trunk-
    based-development?hl=ja
    https://cloud.google.com/blog/ja/products/gcp/using-the-four-
    keys-to-measure-your-devops-performance
    https://ca-base-next.cyberagent.co.jp/2022/sessions/developer-
    productivity/
    https://rheb.hatenablog.com/entry/2021/08/24/
    トランクベース開
    発について
    27
    

    View Slide