2年間育てあげたブランチ戦略を人類のために公開する。

はじめに

こんにちは、SRE Unitの北浦(@kitta0108)です。

皆様、今日も元気にブランチを切っていますか？

僕は今まで、脳死でDevelopブランチを切っては、ただただ空を見つめる・・・そんな人生を送っていました。

そんな僕にも救いの光が差し込みまして、とても上手に運用しているなと思うチームから、運用論や具体的な方法を聞くことができました。今回はその内容をご紹介したいと思います。

※ 社内では発案者である下地さん(@primunu)のお名前をお借りして「shimoji-flow」と呼ばれているそうです。便宜上、当ブログでもそのように呼ばせていただこうと思います。

たかがブランチ戦略、されどもブランチ戦略。システム運用の安定化という観点でも、開発アジリティ向上という観点でも、ブランチ戦略を精錬させ、日々見直しをかけていくことは投資対効果の高いものだと個人的には思っています。

内容のご紹介に入る前に、僕らがGitを運用するにあたって、考慮するべきものは一体どのようなものがあるのか、書き出してみました。

上記を踏まえ、ブランチの構成、運用サイクルを以下のようにしました。

shimoji-flowでは、デリバリーの速度と信頼性の向上を実現するために、 STG/PRD環境向けのデリバリーに関しては、ビルドとデプロイのトリガーを分離させています。

ビルドの責務はReleaseブランチのGitHashをイメージタグとして、コンテナレジストリへのプッシュまでを行うこととし、 Releaseブランチに機能群が出揃ったタイミングでビルドのワークフローを実行するようにしています。

また、同じビルドから作成されたコンテナイメージをSTG/PRD環境で参照するようにもしています。

このように一つのコードベースによる複数のビルド & デプロイが実行されることにより、

環境差異を最小限に抑えた検証が実現できる = 信頼性の向上

ビルドが事前に行われている = PRD環境へのデリバリーの高速化

が実現できていると感じます。

※ ご参考: The Teweleve-Factor App I. CodeBase https://12factor.net/codebase

さて、ちゃんと冒頭に述べた要件が満たされているか振り返ってみましょう。

->Releaseブランチによる各環境へのデプロイ後、環境名のブランチにマージすることにより、コードベースで適用状態がわかるようになりました。

->開発の進行においては、Releaseブランチへのマージだけを考えれば良いという点でとてもシンプルかと思っています。ビルドやデプロイのワークフローも必ずReleaseブランチから実行されるという点も仕組み的にシンプルですよね。

->上記に述べたデリバリーの仕組みにより実現できました。

->各環境名のブランチにリリース後、マージする運用を取り入れているので、いざ切り戻しが必要になった場合、そのブランチのどのコミットまで戻せばいいのかという点に議論は収束されます。環境名のブランチが存在するのでパッと見の可視性が高いのも個人的に○な点かなと思います。

shimoji-flowいかがでしたでしょうか。

さすが2年間運用していて、たくさん改善もされているとのことだったので、完成度の高いものだと個人的には思いました。

良きものは世に出さねばと思って筆を取らせていただいた次第でしたが、みなさんにも、ブランチ戦略見直しのきっかけや、プラクティスの取り入れなどで活用いただいたら大変に嬉しく思います！！