Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

Taiga Sakaguchi

January 30, 2023
Tweet

More Decks by Taiga Sakaguchi

Other Decks in Programming

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