Upgrade to Pro — share decks privately, control downloads, hide ads and more …

永続複数ブランチ運用は『単一のコードベース』と言えるのか / What are your ju...

Tori Hara
September 03, 2021

永続複数ブランチ運用は『単一のコードベース』と言えるのか / What are your justifications for the multi-branches?

Talked at "CI/CD Conference 2021 by CloudNative Days" #CICD2021.

https://event.cloudnativedays.jp/cicd2021/talks/1129

Tori Hara

September 03, 2021
Tweet

More Decks by Tori Hara

Other Decks in Technology

Transcript

  1. twitter.com/toricls Tori Hara / Sr. Product Developer Advocate Elastic Containers,

    AWS ❤ AWS Fargate, AWS App Runner, AWS Lambda toricls ✨
  2. twitter.com/toricls 本⽇のセッションは… ▶︎ The Twelve-Factor App が対象としているような「Web サービス」を開発・運⽤ されている皆様にお伝えしたいと考え、作ったセッションです ▶︎

    そして、そのサービスの根幹をなす「アプリケーション」が本⽇のトピックの対象です ▶︎ Kubernetes や AWS のサービスそのものは本セッションの対象ではありません🙏
  3. twitter.com/toricls Q: なぜ永続的なブランチが複数必要なんですか? ▶︎ リリースタイミングの明⽰的なコントロール ▶︎ フィーチャーフラグなどの実装より低コストになることも ▶︎ 前回リリースからの差分確認の容易性 ▶︎

    (ホントに容易ですか?GitHub の PR 画⾯が使いやすいってだけだったりしませんか?) ▶︎ 本番環境リリース⽤ブランチを触れる⼈物を絞りたい ▶︎ 太古よりよくある話 ▶︎ 環境別に異なるファイルが必要になるケースをカバーしたい ▶︎ 開発環境でだけ必要な依存パッケージ、本番環境でだけ必要な設定値、… ▶︎ いつもそうやってるから ▶︎ ハイ ▶︎ etc., etc.
  4. 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
  5. twitter.com/toricls なぜ The Twelve-Factor App は 1:N を重視するのか ▶︎ 開発環境と本番環境の差異を最⼩限に抑えられれば…

    ▶︎ 実⾏環境間での移植性の最⼤化 ▶︎ 最適なコンピュートオプション選択の容易性 ▶︎ システムアーキテクチャの柔軟性 ▶︎ ⼿動オペレーションの最⼩化と⾃動化 ▶︎ 継続的デプロイによるアジリティの最⼤化 ▶︎ アジリティ、アジリティ、アジリティ ▶︎ 短命なテスト環境構築の容易性も向上する
  6. 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
  7. 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
  8. twitter.com/toricls 複数の永続ブランチ ▶︎ dev → release の⼀⽅向マージしかしないルールなので⼤丈夫です ▶︎ ホントですか?例外的な作業してないですか? ▶︎

    ビッグバンリリースになっていませんか? ▶︎ 差分を Principal Engineer がしっかりチェックしているので⼤丈夫です ▶︎ dev/release 間の差分が想定範囲内であることをどうやって担保していますか? ▶︎ Principal Engineer の時間をそんなことに使って⼤丈夫ですか? ▶︎ “環境”依存のバグとは無縁ですか? ▶︎ ⼈間の努⼒で複数永続ブランチをなんとか運⽤している、という状態ではありませんか?
  9. 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 ※ 簡単のためテスト関連の項⽬を意図的に省いています
  10. 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本のみ ※ 簡単のためテスト関連の項⽬を意図的に省いています
  11. 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本 全環境で同⼀イメージを使⽤
  12. 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本 全環境で同⼀イメージを使⽤ 無理では?
  13. twitter.com/toricls Q: なぜ永続的なブランチが複数必要なんですか? (再掲) ▶︎ リリースタイミングを明⽰的にコントロールしたい ▶︎ その機能はヨーイドンでリリースしないとマズいものですか?こまめにリリースする⽂化を取り⼊れませんか? ▶︎ シンプルな形(e.g.

    環境変数 + if enabled)から、フィーチャーフラグ実装を⽂化として取り⼊れませんか? ▶︎ 前回リリースからの差分確認が簡単だから ▶︎ 永続ブランチが複数あるために差分が⼤きくなり、結果としてしっかり確認する必要が⽣まれているだけではないですか? ▶︎ 各機能開発やバグフィックスのプルリク確認で⼗分な可能性はありませんか? ▶︎ 本番環境リリース⽤ブランチを触れる⼈物を絞りたい ▶︎ プルリクのマージができる⼈物を絞るだけではだめですか? ▶︎ 所定の条件(CI pass, # of approvals)を満たしたら⾃動でマージされる仕組みでは解決できませんか? ▶︎ 環境別に異なるファイルが必要になるケースをカバーしたい ▶︎ 環境依存の設定値などは、環境変数や実⾏直前に設定値を取得してくる⽅式に変更できませんか? ▶︎ いつもそうやってるから ▶︎ ハイ
  14. 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本 全環境で同⼀イメージを使⽤
  15. 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 # … # … ① ② 全環境で(少なくとも) アプリケーションコードと 主要な依存物が同⼀