AWS Code本（クラウドネイティブファーストストーリー）を書いて思ったブランチ運用の難しさ
出版してから約1ヶ月経過した、「クラウドネイティブファーストストーリー」関連のエントリーになります。私はメインでCodeシリーズによるCI/CDの話を書いたので、実際に運用する上での難しさを少し書こうかと思います。
Gitlab flowによる運用
本書では、「GitLab flow」を採用しています。理由としては、2つです。1つ目はGitHub flowは簡略すぎてリリース後の戻し戦略が組みづらく、並行開発が難しいため、gitflowかGitLab flowにしぼりました。2つ目は、gitflowは少し複雑性が高く頻繁なリリースに向いていないからです。
GitLab flowは適度にシンプルで、アプリケーション開発のライフサイクルにあったブランチ運用ができます。
異常系発生時の運用の難しさ
gitflowであろうが、GitLab flowであろうが何も問題なくリリース処理が進むときは特に苦はありません。運用の難しさが出るのは異常系が発生したときの運用です。
コードレベル
GitLab flowでは基本的にMaster→Pre-production→Productionとリリース成果物が流れていきます。 Pre-production、いわゆるステージング環境で緊急対応が必要なバグが発生した場合はどうするのでしょうか？ 現在の運用では、個別で緊急対応が必要なバグの場合、各環境（今回の例ではPre-production）でHotfixブランチを生成し、修正をします。ProductionへはHotfiwが反映されたバージョンをDeploy、MasterへはローカルへCherrypick（コミットIDをベースに修正内容を取得して反映）をした後に反映をします。
ただし、この流れは緊急フローです。急ぎでないバグが見つかったときは、通常の運用に乗せて、local(featureブランチ）→Master→Pre-production→Productionという対処をすることになります。
アプリケーションレベル
こちらは本書でもいくつかパターンに分けて触れています。例えばデプロイ直後でバグが見つかった場合などはCodeDeployの機能をうまく使うだけで済んだりします。アプリケーションレベルになると、ブランチ運用による対処方法の違いは少ないですが、アプリケーションの正しさはコードにあります。コードにどのように修正を反映するかの考え方は上述のコードレベルの運用が重要なので意識しておく必要があります。
まとめ
ブランチ運用はレガシーシステムであっても、クラウドネイティブシステムであっても重要な要素です。特にクラウドネイティブなシステムでは、デプロイの高速化もキーになるので、コードレベルの運用方法・デプロイされたアプリケーションの戻し方などの意識付けは大切ですね。このあたりのハンズオンもどこかで資料化できたらいいなぁ。
