永続複数ブランチ運用は『単一のコードベース』と言えるのか / 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

Transcript

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

8. twitter.com/toricls
   複数ブランチ
   

   View Slide

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

   View Slide

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

    View Slide

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

    View Slide

12. twitter.com/toricls
    

    View Slide

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

    View Slide

14. 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
    

    View Slide

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

    View Slide

16. 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
    

    View Slide

17. 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
    

    View Slide

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

    View Slide

19. twitter.com/toricls
    1:N の実現
    

    View Slide

20. 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
    ※ 簡単のためテスト関連の項⽬を意図的に省いています
    

    View Slide

21. 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本のみ
    ※ 簡単のためテスト関連の項⽬を意図的に省いています
    

    View Slide

22. 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本
    全環境で同⼀イメージを使⽤
    

    View Slide

23. 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本
    全環境で同⼀イメージを使⽤
    無理では？
    

    View Slide

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

    View Slide

25. 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本
    全環境で同⼀イメージを使⽤
    

    View Slide

26. 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
    # …
    # …
    ① ②
    全環境で(少なくとも)
    アプリケーションコードと
    主要な依存物が同⼀
    

    View Slide

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

    View Slide

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

    View Slide