twitter.com/toricls 複数永続ブランチ運⽤は 『単⼀のコードベース』と⾔えるのか Tori Sep. 3, 2021 - Even you said “The Twelve-Factor App was outdated” -

twitter.com/toricls Tori Hara / Sr. Product Developer Advocate Elastic Containers, AWS ❤ AWS Fargate, AWS App Runner, AWS Lambda toricls ✨

twitter.com/toricls https://speakerdeck.com/toricls/for-whom-that-platform-runs https://speakerdeck.com/toricls/the-debt Mar. 12, 2021 Sep. 9, 2020

twitter.com/toricls 複数永続ブランチ運⽤は 『単⼀のコードベース』と⾔えるのか - Even you said “The Twelve-Factor App was outdated” -

twitter.com/toricls 本⽇のセッションは… ▶︎ The Twelve-Factor App が対象としているような「Web サービス」を開発・運⽤ されている皆様にお伝えしたいと考え、作ったセッションです ▶︎ そして、そのサービスの根幹をなす「アプリケーション」が本⽇のトピックの対象です ▶︎ Kubernetes や AWS のサービスそのものは本セッションの対象ではありません🙏

twitter.com/toricls ※フィクションです

twitter.com/toricls ※フィクションです

twitter.com/toricls 複数ブランチ

twitter.com/toricls さまざまな『複数ブランチ』 ▶︎ 緊急バグフィックスのブランチ ▶︎ たいてい超短命 / day(s) ▶︎ 機能開発、バグフィックスのブランチ ▶︎ わりと短命 / week(s) ▶︎ 永続前提のブランチ ▶︎ main, dev, release, … / year(s) ▶︎ etc., etc.,

twitter.com/toricls さまざまな『複数ブランチ』 ▶︎ 緊急バグフィックスのブランチ ▶︎ たいてい超短命 / day(s) ▶︎ 機能開発、バグフィックスのブランチ ▶︎ わりと短命 / week(s) ▶︎ 永続前提のブランチ ▶︎ main, dev, release, … / year(s) ▶︎ etc., etc.,

twitter.com/toricls Q: なぜ永続的なブランチが複数必要なんですか？ ▶︎ リリースタイミングの明⽰的なコントロール ▶︎ フィーチャーフラグなどの実装より低コストになることも ▶︎ 前回リリースからの差分確認の容易性 ▶︎ (ホントに容易ですか？GitHub の PR 画⾯が使いやすいってだけだったりしませんか？) ▶︎ 本番環境リリース⽤ブランチを触れる⼈物を絞りたい ▶︎ 太古よりよくある話 ▶︎ 環境別に異なるファイルが必要になるケースをカバーしたい ▶︎ 開発環境でだけ必要な依存パッケージ、本番環境でだけ必要な設定値、… ▶︎ いつもそうやってるから ▶︎ ハイ ▶︎ etc., etc.

twitter.com/toricls

twitter.com/toricls 1. コードベース - バージョン管理されている1つのコードベースと複数のデプロイ ▶︎ 『複数のコードベースからデプロイされるアプリケーションは分散システム』 ▶︎ 『分散システムを構成する各アプリケーションには個別に Twelve-Factor を適⽤できる』 https://12factor.net/ja/codebase

twitter.com/toricls 1. コードベース - バージョン管理されている1つのコードベースと複数のデプロイ https://12factor.net/ja/codebase Code repository Production Staging Dev Deploy コードベース:デプロイ = 1:N コードベース:デプロイ = N:N Code repository 1 Production Staging Dev Deploy Code repository 1’ Deploy

twitter.com/toricls なぜ The Twelve-Factor App は 1:N を重視するのか ▶︎ 開発環境と本番環境の差異を最⼩限に抑えられれば… ▶︎ 実⾏環境間での移植性の最⼤化 ▶︎ 最適なコンピュートオプション選択の容易性 ▶︎ システムアーキテクチャの柔軟性 ▶︎ ⼿動オペレーションの最⼩化と⾃動化 ▶︎ 継続的デプロイによるアジリティの最⼤化 ▶︎ アジリティ、アジリティ、アジリティ ▶︎ 短命なテスト環境構築の容易性も向上する

twitter.com/toricls 1. コードベース - バージョン管理されている1つのコードベースと複数のデプロイ (再掲) https://12factor.net/ja/codebase Code repository Production Staging Dev Deploy Code repository 1 Production Staging Dev Deploy Code repository 1’ Deploy コードベース:デプロイ = 1:N コードベース:デプロイ = N:N

twitter.com/toricls 1. コードベース - バージョン管理されている1つのコードベースと複数のデプロイ (再掲) https://12factor.net/ja/codebase Code repository Production Staging Dev Deploy Code repository 1 Production Staging Dev Deploy Code repository 1’ Deploy コードベース:デプロイ = 1:N コードベース:デプロイ = N:N Code repository 1 Code repository 1’ これらは永続ブランチでは？ コードベース:デプロイ = N:N

twitter.com/toricls 複数の永続ブランチ ▶︎ dev → release の⼀⽅向マージしかしないルールなので⼤丈夫です ▶︎ ホントですか？例外的な作業してないですか？ ▶︎ ビッグバンリリースになっていませんか？ ▶︎ 差分を Principal Engineer がしっかりチェックしているので⼤丈夫です ▶︎ dev/release 間の差分が想定範囲内であることをどうやって担保していますか？ ▶︎ Principal Engineer の時間をそんなことに使って⼤丈夫ですか？ ▶︎ “環境”依存のバグとは無縁ですか？ ▶︎ ⼈間の努⼒で複数永続ブランチをなんとか運⽤している、という状態ではありませんか？

twitter.com/toricls 1:N の実現

twitter.com/toricls 現代のコンテナアプリケーションデリバリの概略 👤 Code repo Push Build system Pull Package Container image repo Push Pull Run Container runtime Run Container agent ※ Several tests should be included CI Container orchestrator 👤 De fi ne CD system Or CD ※ Several tests can be included ※ 簡単のためテスト関連の項⽬を意図的に省いています

twitter.com/toricls 理想のコンテナアプリケーションデリバリ 👤 Code repo Push Build system Pull Container image repo Package Push 📦 awesome-image:v1 Pull Production 📦 awesome-image:v1 Staging Pull 📦 awesome-image:v1 Dev Pull 📦 awesome-image:v1 全環境で同⼀イメージを参照 永続ブランチは 1本のみ ※ 簡単のためテスト関連の項⽬を意図的に省いています

twitter.com/toricls 理想のコンテナアプリケーションデリバリ CI CD 👤 Code repo Packaging Container image repository Deploy to dev Deploy to staging Deploy to production ※ 簡単のためテスト関連の項⽬を意図的に省いています Push 📦 awesome-image:v1 Automatic / Approval / Manual Action Automatic / Approval / Manual Action Deploy 📦 awesome-image:v1 Deploy 📦 awesome-image:v1 Deploy 📦 awesome-image:v1 永続ブランチは1本 全環境で同⼀イメージを使⽤

twitter.com/toricls 理想のコンテナアプリケーションデリバリ CI CD 👤 Code repo Packaging Container image repository Deploy to dev Deploy to staging Deploy to production Automatic / Approval / Manual Action Automatic / Approval / Manual Action ※ 簡単のためテスト関連の項⽬を意図的に省いています Push 📦 awesome-image:v1 Deploy 📦 awesome-image:v1 Deploy 📦 awesome-image:v1 Deploy 📦 awesome-image:v1 永続ブランチは1本 全環境で同⼀イメージを使⽤ 無理では？

twitter.com/toricls Q: なぜ永続的なブランチが複数必要なんですか？ (再掲) ▶︎ リリースタイミングを明⽰的にコントロールしたい ▶︎ その機能はヨーイドンでリリースしないとマズいものですか？こまめにリリースする⽂化を取り⼊れませんか？ ▶︎ シンプルな形(e.g. 環境変数 + if enabled)から、フィーチャーフラグ実装を⽂化として取り⼊れませんか？ ▶︎ 前回リリースからの差分確認が簡単だから ▶︎ 永続ブランチが複数あるために差分が⼤きくなり、結果としてしっかり確認する必要が⽣まれているだけではないですか？ ▶︎ 各機能開発やバグフィックスのプルリク確認で⼗分な可能性はありませんか？ ▶︎ 本番環境リリース⽤ブランチを触れる⼈物を絞りたい ▶︎ プルリクのマージができる⼈物を絞るだけではだめですか？ ▶︎ 所定の条件(CI pass, # of approvals)を満たしたら⾃動でマージされる仕組みでは解決できませんか？ ▶︎ 環境別に異なるファイルが必要になるケースをカバーしたい ▶︎ 環境依存の設定値などは、環境変数や実⾏直前に設定値を取得してくる⽅式に変更できませんか？ ▶︎ いつもそうやってるから ▶︎ ハイ

twitter.com/toricls 理想のコンテナアプリケーションデリバリ (再掲) CI CD 👤 Code repo Packaging Container image repository Deploy to dev Deploy to staging Deploy to production Automatic / Approval / Manual Action Automatic / Approval / Manual Action ※ 簡単のためテスト関連の項⽬を意図的に省いています Push 📦 awesome-image:v1 Deploy 📦 awesome-image:v1 Deploy 📦 awesome-image:v1 Deploy 📦 awesome-image:v1 永続ブランチは1本 全環境で同⼀イメージを使⽤

twitter.com/toricls 永続ブランチは1本 とはいえ開発環境にだけ必要な依存パッケージが… CI CD 👤 Code repo Packaging Container image repository Deploy to dev Deploy to staging Deploy to production Automatic / Approval / Manual Action Automatic / Approval / Manual Action ※ 簡単のためテスト関連の項⽬を意図的に省いています Push 📦 awesome-image:v1 Deploy 📦 awesome-image:v1-dev Deploy 📦 awesome-image:v1 Deploy 📦 awesome-image:v1 📦 awesome-image:v1-dev # Docker fi le FROM awesome-image:v1 # Add “special” dev packages # … # … ① ② 全環境で(少なくとも) アプリケーションコードと 主要な依存物が同⼀

twitter.com/toricls あなたのリポジトリは 『単⼀のコードベース』ですか？

twitter.com/toricls あなたのリポジトリは『単⼀のコードベース』ですか？ ▶︎ 思考停⽌の複数永続ブランチは必要ないかもしれない ▶︎ 複数永続ブランチ運⽤は(少し考えれば/少し頑張れば)やめられるかもしれない ▶︎ 単⼀永続ブランチの実現はデリバリの信頼性を圧倒的に向上させる ▶︎ もちろん他にもメリットがある ▶︎ The Twelve-Factor App は今でも⽰唆に富む数々のプラクティスを得られる (たしかにちょっと古くなった部分はあるけど) Thank You!