トランクベース開発について振り返る
トランクベース開発を振り返る
トランクベース開発を行うプロジェクトに入り、実際に体験をしてみて感じた所感について
トランクベース開発とは？
DevOps Research and Assessment（DORA）にて以下のように述べられている
各開発者が自分の作業を小さなバッチに分け、その作業を1日に少なくとも1回（場合によっては数回）トランクにマージする。これらのアプローチの重要な違いは、スコープです。フィーチャーブランチには通常複数の開発者が参加し、数日から数週間の作業を要します。対照的に、トランクベースの開発におけるブランチは、通常数時間以内で、多くの開発者がそれぞれの変更を頻繁にトランクにマージします。
https://dora.dev/devops-capabilities/technical/trunk-based-development/
作業ブランチ（feature buranch）を数時間以内にトランクにマージしていくと理解しています。
マーティン・ファウラー氏も継続的デリバリーをするために、高速にブランチ運用をしていくような話をしてくれています。
進め方における約束事
適応したトランクベース開発についてやったことをまとめてみました。
- featureブランチは切らず、main(master)ブランチのみで運用を行う
- ペアプロ or モブで進める
- e2eが通る実装のみpushする
それぞれについて、もう少し述べていきます。
mainブランチのみの運用
最初に紹介していたDORAでも実質トランクベースにはプルリクは存在しないような話があります。
In trunk-based development, developers push code directly into trunk.
そのため、できる限り早くリリースし、フィードバックを得たいと言う所でmainブランチのみの運用にしています。
featureブランチの運用があることで、いくつか手順が増える
- featureブランチを作成する
- 実装を行う
- 実装したコードをpushする
- GitHubでPR作成する
- コードレビューする
- mainブランチにマージする
手順は我々が設定した価値においてどれだけ重要なのだろうか考えてみた時に
トランクベースにおいて、小さく実装を進め、mainにマージするということは、リリースを頻度高く行う事でもあると思います。
featureブランチの運用は価値提供まで時間とコストが増える手順だと考え「トランクに直接pushする」という方針を取りました。
ペアプロ or モブで進める
mainブランチのみの運用にすることで以下の課題が出てきます。
作業ブランチを切らないということは、プルリクエストを作成しないため、レビューをしないということになる
そのため、常にレビューがされている必要性が出てくる
そこでペアプロを導入し、常にコードをレビューしながら進める状態にすることで
レビュー工程の省略とコードの品質担保をペアプロを導入することで解決しています。
e2eが通る実装のみpushする
ペアプロによるコードの品質担保にプラスして、常に仕様を満たしている状態を保つため
e2eを実装しています。
ここでは、ATDD（受け入れテスト駆動開発）を採用し、開発を進めており、
そのためローカル環境でのテストはもちろんですが、CIにも組み込むことで
継続的にデプロイ可能な状態を維持しています。
Tips的な話
他にも導入している内容についてもまとめます。
git diff
ペアプロを採用していることもあり、実装の引き継ぎが発生する場合は git diff で差分を出し、patchファイルとしてエクスポートする
適応する場合は、共有されたpatchファイルをダウンロードし、applyして続ける
wip
開発途中だけどキリが割と良さそうな状態の場合はpushしたくなるため
その場合はe2eにwipを付与し、CI上では流れないような工夫をしています。
所感
実際にやってみた所感としては、とても開発体験が上がったなと思います。
特に体験として印象深かったのは、ブランチ運用が存在しないため
サッと開発に入ることができ、リリースまでシンプルでレビューもPRも不要という流れが何よりよかった。
トランクベース開発のレポジトリからfeatureブランチの運用を行なっているレポジトリで
久しぶりに作業をした時、とても感じました。
デプロイまでのフローも流れるような速度でできるため
停滞することが基本的にないなという印象です。
特に、マイクロサービスなど採用しているサービスは、そもそも小規模で独立しているため、トランクベース開発は相性が良さそうです。
一方で、トランクベース開発を行うには、ある程度プラクティスによる補完が必要不可欠であると思いました。
実質ブランチ運用が無い点
ブランチ運用をしなくとも安心してリリースできる状態であり、それを維持し続ける必要があるという話にもなると思われるので、ペアプロによるソースレビューやe2eでの担保が必要
モノリス開発を行なっているサービスでは導入は難しそうな点
全員がmainブランチで作業するということは、ビルド時間やe2eテストが数分で終えることができないと、結局全体を通して停滞する恐れがありそう
また、ドメイン毎にうまくチーム分けできていないとコンフリクトの嵐も考えられる
まとめ
- トランクベース開発は、サービスにおいてのフィードバックサイクルを高速に回すことができる
- 導入するには、ある程度必要条件や、推奨される環境・プラクティスを導入し、保管する必要がありそう
- モノリスよりもマイクロサービスなど依存し合わないサービスと相性が良さそう
Discussion