DevOpsDays Tokyo2024にオンラインで参加しました！
ユーザの要望を可能な限り早くデリバリーできるエンジニアを目指す私としては、トランクベース開発というキーワードがやはり気になるところでした。
イベントでトークセッションをしていたカケハシ社の「Value-Driven DevOps Team〜価値貢献を大切にするチームがたどり着いたDevOpsベストプラクティス〜」で聞いた内容と、
自分なりに調べた内容を組み合わせて、素早くユーザに機能をデリバリーするためのトランクベース開発についてまとめていこうと思います！
↓DevOpsDaysで聴講したセッションの資料はこちら↓
引用: Value Driven DevOps Team ~価値貢献を大切にするチームがたどり着いたDevOpsベストプラクティス~(https://speakerdeck.com/kakehashi/value-driven-devops-team)
誰に対する何の記事か？
「ユーザが求めるものを早く作りたいと思っている人」や「トランクベース開発について知りたい人」
に向けた、
トランクベース開発の理論や実例を紹介しつつ、学んだことを共有する記事です。
記事の概要
- カケハシのトークセッションが面白かったので共有したい！
- トランクベース開発はmainブランチに細かくコミットをしていくブランチモデル
- リリースしているものに変更を適用するスピードを上げられる
- 現場で回すには作業の進め方に注意が必要
トランクベース開発ってなに？
ざっくりいうと、
- ブランチモデル(≒ブランチ戦略)の一種
- 「トランク」と呼ばれる単一のブランチに対して細かく修正をしていく
- 以下二つのスタイルがある(下図参照)
- mainに直接コミットをするスタイル
- 短命なfeatureブランチを作って、プルリクエストをマージするスタイル
- 修正が小さいのでマージが楽で、ビルドも壊れず、そして末長い幸せを得られる
mainに直接コミットをするスタイル
引用: Trunk Based Development: Introduction https://trunkbaseddevelopment.com/
短命なfeatureブランチを作って、プルリクエストをマージするスタイル
引用: Trunk Based Development: Introduction https://trunkbaseddevelopment.com/
ブランチモデルとブランチ戦略の違い
世の中のWebページでは混同して使用されてるように見えるので、正しい意味をご存知の方がいたら優しくコメントしてください。
ちょっと調べてみたところ、↓の理解です。
ブランチモデル: 具体的なブランチの運用スキーム(git-flow, github-flow等)
ブランチ戦略: ブランチモデルを取り入れつつ、よりリリースフロー等も含めた運用スキーム
トランクベース開発は現場で本当に有用なものなのか？
良いプロダクトを作る上では、ユーザが得た洞察をプロダクトに素早く反映し、実験しながらプロダクトをよくしていくのが重要だと思います。
そんな私は、「トランクベース開発、なんかアジャイルに開発を進められそうで良さそうじゃん」と思いましたが、
少し冷静になって開発者目線でトランクベース開発は使えるものなのだろうか？と整理しました。
これができると何がうれしいか？
- commitのサイクルが短いため、
- トランク(mainブランチのコード)の変更頻度が高く、リリース頻度を上げられる(=ユーザからの要望をデリバリーする時間を短縮できる)
- mainに対する一回の変更量が少ないため、mainが壊れる可能性が低いし、壊れても原因特定が迅速にできる
- 開発者体験として、タスク消化のリズムができるため、集中して開発に取り組める
大変そうなポイント
- 数時間で終わるタスクに分けるのがそもそも大変そう
(例: ECサイトにおいて、商品登録機能を追加する時、どうしたら数時間単位の作業に分けられるか？) - 複数の開発者が同時に開発している場合、
- コンフリクトが頻繁に発生しそう
- デプロイに気を使いそう
- mainにマージした後のCI/CDのワークフロー中に別のコミットが走らないようにする等、デプロイ作業に気をつかいそう
- デプロイ時に新しい機能を組み込んだシステムと新しい機能が組み込まれてないシステムがうまく連携できるようにしなければならなそう
現場で適用するために
現場で適用する嬉しさはわかるが、大変そうなポイントが大変そうだなあというのが正直な感想でした。
そこで、DevOpsDays Tokyo2024でトークセッションをしていたカケハシさんのお話を例に現場で適用するための洞察を得ようと思います。
カケハシでの事例
セッションで聞いた話を元に実際にはどのように開発を回してるか？を少しだけ書いてみます。
↓[再掲]詳細や正確な情報は元資料をご覧ください↓
引用: Value Driven DevOps Team ~価値貢献を大切にするチームがたどり着いたDevOpsベストプラクティス~(https://speakerdeck.com/kakehashi/value-driven-devops-team)
現場でどのようにして回してるのか？
- ブランチモデル
- mainブランチに対して寿命の短いブランチを切ってマージしていくスタイルを選択している
- 開発タスクはモブプロ or ペアプロで実施
- CIとCDを分けて実施
- フィーチャーフラグを使って、機能の公開を制御している
- チームとして制約を受け入れている
- 本番環境を壊さないようにタスクを分割したりデプロイを考慮しながら開発を進める
- チームで1つのユーザストーリーに取り組む
このセッションの話のなかで、私の疑問に対する答えがあるかなと思いました。
大変そうなポイントに対する答え
先ほど挙げた大変そうなポイントに現場ではどのように対応してるのでしょうか？
セッションの資料から読み取ってみましょう。
複数の開発者が同時に開発している場合にコンフリクトが頻繁に発生しそう
これは書いてある通り、チームで一つのユーザストーリーに取り組むことで対応しているようです。
ただこれは、新規機能を同時に複数開発するようなことはできないという制約を受け入れることになると思います。
0→1のプロダクト開発というよりも、1→10という感じでスケールしたり改善していくようなプロダクト開発だからこそ適用できる方法なのかもなと思いました。
プロダクトの性質やライフサイクルのフェーズによって適切な開発手法が異なると思いますが、トランクベース開発は、
- ユーザの課題を収集しそれをプロダクトに落とし込んで実験したい
- すでに動作するプロダクトがある
- プロダクトを細かい改善でよくしていきたい
という状況で威力を発揮するのかなと思いました。
デプロイ時に気を使いそう
デプロイ時に気を遣いそうというものについて、下記二つに引っかかりそうだなということを書いていました。
- mainにマージした後のCI/CDのワークフロー中に別のコミットが走らないようにする等、デプロイ作業に気をつかいそう
- デプロイ時に新しい機能を組み込んだシステムと新しい機能が組み込まれてないシステムがうまく連携できるようにしなければならなそう
この大変そうなポイントに対して、こちらのセッションでは
- チームでひとつのユーザストーリーに取り組む
- タスク分割の段階で、デプロイの順番を気にすることで新旧バージョンが混ざっても正しく動くように注意して開発する
というので対応してるとのことでした。
チームでひとつのユーザストーリに取り組むというのは、チームの規模にもよるのかもなとも思いました。
以前、認定スクラムマスターの研修を受けた際にモブプログラミングについて学びましたが、
モブプログラミングを徹底して実施するチームであれば、チームでひとつのタスクしかやらないで、全員でユーザに機能を届けるまでを短期間でやり切る進め方をするようです。
今思えば、それもトランクベース開発に近いやり方だったんだろうなと思いました。
数時間で終わるタスクに分けるのがそもそも大変そう
これに関しては、そうなるようにタスクを分けてるということでした。
個人的にはこれに関しては、かなり「職人技」なのではと思います。。。
私自身、1週間スプリントのスクラムで開発していますが、PBIをSBIにうまく分割することができてないこともあります。
1週間スプリントのタスクの分割ですら失敗することもありますが、長くても一日で終わるタスクへの分割はさらに難しいのではないかと思います。
個人的に答えを持っていないところなので、引き続き学びたいなと思いつつ、気軽にChatGPTに聞いてみました。
ChatGPT曰く、一機能の開発においても、ユーザに価値を届けるのには至らないがビルドもテストも通る最小限の単位でタスクを進めていくように見えますね。
ユーザストーリーをタスクに分割するフェーズにて、うまくタスクを分割すると開発の見通しも立ちやすいでしょうし、壊れにくいソフトウェア開発ができると思います。
まとめ
トランクベース開発とは？というところから、それを現場に回すためのノウハウについて書いてみました！
- トランクベース開発はmainブランチに細かくコミットをしていくブランチモデル
- リリースしているものに変更を適用するスピードを上げられる
- 現場で回すには作業の進め方に注意が必要
という感じです！
トランクベース開発の良さや、実現するための難しさみたいなところが伝われば良いなと思います。
カケハシさん、面白いセッションありがとうございました!
補足
人生初記事なので、読みづらいところ等あるかもしれません。
お気づきの点がございましたら、優しくご指摘いただけると嬉しいです。