Contenu connexe Similaire à トランクベース開発を活用して爆速に開発した話 (20) トランクベース開発を活用して爆速に開発した話6. Philosophy
6
Branches create distance between developers and we do not want that
— Frank Compagner, Guerrilla Games
“
”distance”が大きいほど以下の問題が生じやすい。
* 予期せぬ不具合を引き起こす
* 差分が大きくなりすぎてマージが難しい
* 他の開発者と作業内容が被る
8. Practice
8
* ペアプロ (同期レビュー)
* 同期レビューイベント
* trunkに入れたらすぐにレビュー (非同期レビュー)
DO NOT: Pull Requestを作成してApproveされるまで待ってからMerge (非同期レビュー)
Quick Code Review
* 完成していない機能を環境ごとにOn/Offを切り替えるしくみ
Feature Flags
9. Metrics
9
* アクティブなブランチ数: 3つ以下が望ましい
* Code Freezeの期間: Code Freezeはないほうが望ましい
* trunkにマージする頻度: 1日1回以上
* Approveにかかる時間: ゼロに近いほどよい
https://cloud.google.com/solutions/devops/devops-tech-trunk-based-development/?hl=ja
17. Metrics
17
* アクティブなブランチ数: 3つ以下が望ましい
* Code Freezeの期間: Code Freezeはないほうが望ましい
* trunkにマージする頻度: 1日1回以上
* Approveにかかる時間: ゼロに近いほどよい
https://cloud.google.com/solutions/devops/devops-tech-trunk-based-development/?hl=ja
18. Metrics
18
* アクティブなブランチ数: 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
Notes de l'éditeur トランクベース開発とは、という説明をする前に、トランクベース開発とよく比較されるGitFlowのおさらいからいきます GitFlowはfeature、develop、master(main)ブランチと役割を持ったブランチが複数あり、基本的には決まった順序でマージしていくブランチモデルです
Developブランチは開発環境の最新として扱い、開発者はdevelopブランチからfeatureブランチを作成する。
Releaseブランチはproductionリリースの準備をするブランチ
master/mainブランチは常にRelease readyなブランチ。mainブランチ = 本番環境としている開発現場も多いのではないでしょうか。 根底にある考え方として「ブランチは開発者との距離(distance)を作ってしまう」があります
distanceが大きいほど様々な問題を引き起こします。
トランクベース開発ではこのdistanceを最小化することを目指しています。 バグが見つかったら修正をtrunkに入れていくので、必然的にcherry-pickがない世界 Feature Flags
小さい単位でRelease Readyなコミットを積んでいくためのプラクティスです。
Feature開発は完成してからマージするというスタイルだと、PRが大きくなってしまいます。
Featureが完成していなくても、マージし、本番環境などではFeatureをOffにし、開発時には有効にすることで、Featureが未完成でもtrunkにマージすることできます。 Google CloudではApproveにかかる時間は「開発の一環として実行されるコードレビューを同期アクティビティとして行う方法を見つけましょう」と書かれているのですが、マージ前のレビューは必須ではないので、非同期レビューの場合は、レビューを待たずにマージするのでもよいと思います。 トランクベース開発はすべての開発現場におすすめできるわけではありません。
同期的なレビューかApproveなしにマージするので、OSSには不向きです。
また、メンバー間にスキル差があったり、コードレビューを教育的な観点で行っている場合も不向きです。
だいぶ癖の強いブランチモデル・開発プロセスになるので、特に現在GitFlowで開発されているチームは「よし、明日からトランクベース開発をやってみよう」と言って、このやり方をそのまま実践していくのは難しいと思います。
実際、私たちもそうでした。
では、次にどのようにトランクベース開発を取り入れていったのかをお話します。 もともとはAuthチームも他のチーム同様にGitFlowで開発していました。
リリースフローや各チームで使っているCloudFormationのテンプレートなどGitFlowを前提としたものになっています。 チームメンバーが他のチームと兼任していたりするので、他のチームで活動しているときに「このPRレビューしてくれないと先に進めない」みたいな状況になるのも回避したかった 認証認可基盤はすべてサービスに使われているため、壊すとすべてのサービスが動かなくなってしまうため、開発環境といえど壊してはいけないという心理が働く
ゆえに、Authチーム的にはdevelopはもともとRelease Readyのコードだったので、相性はよかったと思っている