Link
Embed
Share
Beginning
This slide
Copy link URL
Copy link URL
Copy iframe embed code
Copy iframe embed code
Copy javascript embed code
Copy javascript embed code
Share
Tweet
Share
Tweet
Slide 1
Slide 1 text
© 2024 Wantedly, Inc. PR マージのあらゆる ブロッキングを回避する技術 Gotanda.rb #58 Apr 24 2024 - Sora Ichigo
Slide 2
Slide 2 text
© 2024 Wantedly, Inc. ⾃⼰紹介 名前 市古 空 (Sora Ichigo) 所属 ● ウォンテッドリー株式会社 ● バックエンドエンジニア ● DevOps 推進チームリード SNS ● X: @igsr5_
Slide 3
Slide 3 text
© 2024 Wantedly, Inc. 今回のテーマ トランクベース開発 ⼩さなパッチを頻繁にデプロイしていく DevOps ケイパビリティの⼀つ https://dora.dev/devops-capabilities/technical/trunk-based-development/
Slide 4
Slide 4 text
© 2024 Wantedly, Inc. トランクベース開発 構成要素 「作業の分割」 x 「迅速なデプロイ」
Slide 5
Slide 5 text
© 2024 Wantedly, Inc. 構成要素 「作業の分割」 x 「迅速なデプロイ」 今回のメインテーマ こちらが今回のメインテーマ
Slide 6
Slide 6 text
© 2024 Wantedly, Inc. ⽬次 1. トランクベース開発の全体像 2. PR マージを阻害する外部要因 3. ウォンテッドリー事例 (Ruby で実践してみる)
Slide 7
Slide 7 text
© 2024 Wantedly, Inc. 1. トランクベース開発の全体像
Slide 8
Slide 8 text
© 2024 Wantedly, Inc. 導⼊ ⼀般論として、プロダクト開発を⾼速かつ安全に進めるためには 変更をなるべく “⼩さな単位で頻繁に本番に出していくこと”が⼤事
Slide 9
Slide 9 text
© 2024 Wantedly, Inc. よく⽐較される 2 つの開発スタイル (A) リリースブランチを切って変更を集約する (B) リリースブランチを切らずに常に全ての変更を本番に出す トランクベース開発は (B) を指す
Slide 10
Slide 10 text
© 2024 Wantedly, Inc. (A) リリースブランチを切って変更を集約する https://dora.dev/devops-capabilities/technical/trunk-based-development/
Slide 11
Slide 11 text
© 2024 Wantedly, Inc. (B) リリースブランチを切らずに常に全ての変更を本番に出す https://dora.dev/devops-capabilities/technical/trunk-based-development/
Slide 12
Slide 12 text
© 2024 Wantedly, Inc. トランクベース開発 (B) の利点 ● 変更1回あたりの認知負荷の低減 ● テスト容易性の向上 ● 本番環境から得られるフィードバックの最⼤化 ● 変更1回あたりのインシデントリスクの低減 ● 頻繁なコンフリクトの予防
Slide 13
Slide 13 text
© 2024 Wantedly, Inc. トランクベース開発 (B) の利点 これらは開発プロセスのなかで継続的に価値を発揮し、 機能開発のスピードや安定性に⼤きく影響する
Slide 14
Slide 14 text
© 2024 Wantedly, Inc. 2. PR マージを阻害する外部要因
Slide 15
Slide 15 text
© 2024 Wantedly, Inc. 問題 実装やコードレビューは完了しているのに ”外部要因によって PR マージがブロックされる” ケースがある
Slide 16
Slide 16 text
© 2024 Wantedly, Inc. 具体例 ● QA テスト、デザイナーや PdM による最終確認など ● まだユーザーには⾒せたくないケース ● 関連サービスの実装が追いついていないケース ● ... 受け⼊れ条件を満たしている か確認したい! 受け⼊れテストが終わるまで PRマージは待とう
Slide 17
Slide 17 text
© 2024 Wantedly, Inc. 最も素朴なアプローチ “外部要因が取り除かれるまで PR を寝かしておく” が最も素朴なアプ ローチ。 ⼀⽅でこれはトランクベース開発の恩恵を諦めることを意味する。
Slide 18
Slide 18 text
© 2024 Wantedly, Inc. トランクベース開発と外部要因の解決をなんとか両⽴できないか? 実は、これらの外部要因によるブロックは⼯夫次第で回避可能
Slide 19
Slide 19 text
© 2024 Wantedly, Inc. 基本となる考え⽅ マージできない外部要因は “何かしらの条件分岐“ を実装することで⼤抵 回避できる ● 環境変数による分岐 ● Feature Flag による分岐 ● 認証ユーザーによる分岐 ● Basic Auth による分岐 ● ...
Slide 20
Slide 20 text
© 2024 Wantedly, Inc. 適⽤例 ● 「この変更はまだ PdM チェックが終わっていないから、、、」 ○ → 本番環境のみ旧実装を出せばマージ可能 ● 「この変更は関連マイクロサービスの実装を待たないと、、」 ○ → Feature Flag で新実装を隠蔽すればマージ可能 次ページから詳しく解説します
Slide 21
Slide 21 text
© 2024 Wantedly, Inc. 3. ウォンテッドリー事例 Ruby で実践してみる
Slide 22
Slide 22 text
© 2024 Wantedly, Inc. 実際にあったシナリオ ● PdM チェックが終わっていないのでマージできない ● 開発途中の変更をユーザーに⾒せたくないのでマージできない ● 新規サイト⽴ち上げでリリース当⽇まで本番環境が作れない
Slide 23
Slide 23 text
© 2024 Wantedly, Inc. QA テストが終わっていないのでマージできない エンジニア PdM コードレビューまで完了! 受け⼊れ条件を満たしている か確認したい!
Slide 24
Slide 24 text
© 2024 Wantedly, Inc. アンチパターン エンジニア PdM コードレビューまで完了! 受け⼊れ条件を満たしている か確認したい! 受け⼊れテストが終わるまで PR マージは待とう
Slide 25
Slide 25 text
© 2024 Wantedly, Inc. 何が問題か PR ⽣存期間が⻑くなることによる⽣産性低下 ● いつまでも未マージの PR がチームの認知負荷を増加させる ● 特定ブランチをデプロイしないと QA テストが⾏えない ● ⾒つかった問題の修正が同じ PR に積まれて⾒通しが悪くなる ● 最新 master をいちいち取り込む⼿間がかかる
Slide 26
Slide 26 text
© 2024 Wantedly, Inc. どうするか. 案 エンジニア PdM コードレビューまで完了! 受け⼊れ条件を満たしている か確認したい! Feature Flag で変更を 切り替え可能にして PR マージしよう
Slide 27
Slide 27 text
© 2024 Wantedly, Inc. ウォンテッドリーと Feature Flag こんなコードを書くと 内製 Chrome Extension から 戻り値を override 可能になる リリース‧デプロイ戦略を⽀える技術 | Wantedly Engineering Handbook
Slide 28
Slide 28 text
© 2024 Wantedly, Inc. ウォンテッドリーと Feature Flag Feature Flag が true の時のみ 新実装を出すようにすれば 安全に PR マージできる Chrome Extension は⾮エンジニアでも触れるので QA テストも簡単
Slide 29
Slide 29 text
© 2024 Wantedly, Inc. リッチな Feature Flag がない場合でも params や環境変数、認証ユーザー情報などで代替可能
Slide 30
Slide 30 text
© 2024 Wantedly, Inc. 最後に
Slide 31
Slide 31 text
© 2024 Wantedly, Inc. まとめ トランクベース開発 ⼀般論として、プロダクト開発を⾼速かつ安全に進めるためには 変更をなるべく “⼩さな単位で頻繁に本番に出していくこと” が⼤事 Feature Flag マージできない外部要因は “何かしらの条件分岐“ を実装することで⼤抵 回避できる
Slide 32
Slide 32 text
© 2024 Wantedly, Inc. もっと知りたい ● DORA | DevOps Capabilities: Trunk-based Development ● リリース‧デプロイ戦略 | Wantedly Engineering Handbook ● リリース‧デプロイ戦略を⽀える技術 | Wantedly Engineering Handbook