はじめに

これはなに？

所属チームでブランチ運用を変更するにあたり、周知のための勉強会を開催したところ、思いのほか好評だったのでノリに乗って記事にしたものです。
本記事では、弊チームで抱えていた課題を元に、どのようにGit運用を変更して行ったのかを比較できる形で記載しています。
本記事を通して、gitの運用でお悩みの方の一助となれる記事となれば幸いです。

対象読者

• ブランチ運用にお悩みの方

TL;DR

簡略化したgit-flow → GitFeatureFlowぽいものを導入した運用に変更したら、デプロイにかかる工数がかなり減って嬉しかった。

※ 記事中に画像を載せてあります。画像内にもコメントを記載してますので、画像だけ見てもらえればフロー自体はわかるようになっているはずです。

前提

※所属チームでのルールなどの概要なので読み飛ばしても構いません。

ブランチの運用フロー

git-flowを簡略化したようなフローです。あとで解説付きの図を用いて説明します。

マイクロサービス化したリポジトリの運用

提供しているサービスのスケールや、弊社他サービスとの連携を想定し、
バックエンドを機能単位で複数のGitリポジトリに分割しています。

そのため、各サービスごとにデプロイする必要があり、
また、各マイクロサービスごとに依存関係を考慮しながらデプロイする必要があるため、
モノレポのサービスと比較するとリリース作業に時間がかかります。

※ マイクロサービスの詳細は省略します。ここでは、たくさんGitリポジトリあるんだなくらいの理解で十分です。

リリース頻度が高い

平均で週に2回ほど、多い時は4回行います（行っていました）。
細かいバグ修正や機能追加をいち早く行うために、リリースができるタイミングでリリースをしています。

これまでの運用フロー

登場する用語

• Time
  • 時系列を表すための存在
  • わかりやすくするために記載しているだけですので、特に意識する必要ないです
• feature
  • 機能追加やバグ修正など、開発者がローカルで作業する時に作成するブランチ
• staging
  • ステージング環境と同期しているブランチ
  • 弊チームでは起点となるブランチです
  • stagingへのマージはデプロイ担当者のみ
  • 本番環境での不具合発生を考慮して、検証用にmainのリソースと同期している必要がある
• main
  • 本番環境と同期しているブランチ
  • mainへのマージはデプロイ担当者のみ
    • リリース日にstagingでの機能テスト・リグレッションテストが完了したらリリース

運用フロー図　(簡略版のgit-flowのようなもの)

図中の解説のとおりです。
元々の運用フローは簡略化したgit-flowのようなブランチ運用をしておりました。

なにが課題だったか

デプロイ日が来ないと本番と近い（同等）の環境でのテストができない

「登場する用語」でstagingブランチのルールを記載したとおり、
staging環境へのマージが開発者の任意でできないので、本番と同等の環境での機能テストはこのタイミングでのみしかできません。

また、stagingでのテストでバグが発覚したら、バグの修正を待つか対象のPRをRevertしなければ、その他のPRもmainへのマージができないことになります。
バグの修正を待ち、mainへマージするまでに半日かけてやることもありました。

デプロイ担当者の工数が多くなる

「登場する用語」のstaging, mainに記載のとおり、
staging, mainへのマージはデプロイ担当者が行うこととしています。

デプロイ作業では、stagingデプロイが完了したらSlackに通知が飛び、開発者（もしくはデプロイ担当者）によってstagingでの機能テストが行われます。
複数のPRをマージする際には、順次テストが行われるので、相当時間がかかっていました。

そして、テストを通らなかったものについては、「すぐに修正のPRを出す」 or 「Revertする」などを開発者に依頼（もしくはデプロイ担当者が修正）する必要があり、ここでもコミュニケーションやRevertする工数が嵩むことがありました。

変更後の運用フロー

登場する用語

増えたブランチ

• develop
  • develop環境と同期しているブランチ
  • 開発者任意にマージできる検証用環境
  • レビューを通す前にマージ可能

あとは同じですので、読み飛ばしてしまって良いです。

• Time
  • 時系列を表すための存在
  • わかりやすくするために記載しているだけですので、特に意識する必要ないです
• feature
  • 機能追加やバグ修正など、開発者がローカルで作業する時に作成するブランチ
• staging
  • ステージング環境と同期しているブランチ
  • 弊チームでは起点となるブランチです
  • stagingへのマージはデプロイ担当者のみ
  • 本番環境での不具合発生を考慮して、検証用にmainのリソースと同期している必要がある
• main
  • 本番環境と同期しているブランチ
  • mainへのマージはデプロイ担当者のみ
    • リリース日にstagingでの機能テスト・リグレッションテストが完了したらリリース

運用フロー図（GitFeatureFlowのような形）

developブランチが追加されたことで、図が少しごちゃつきました。

基本的なフローは元々のフローとそこまで大差ありません。
変更されているのは、feature→stagingのPRと同時にfeature→developへのPRが作成され、レビュー前にマージできるようになったことです。

開発者目線でも、developブランチのマージが可能になっただけで、それ以外は特に変更はありません。

なにが良くなったか

デプロイ日が来ないと本番と近い（同等）の環境でのテストができない問題

デプロイのタイミングに関わらず、開発者任意のタイミングでdevelopへマージできるようになったため、本番に近い環境でのテストが容易となりました。ここでバグが発覚したら、featureブランチで修正して再度pushするだけで良くなります。

デプロイ担当者の工数が多くなる

「stagingにマージ可能なPR = developでの機能テストが通っているPR」
という状態とすることで、デプロイ日のstagingでの機能テストが不要となりました。

なので、デプロイ日にはリリースするものを全て取り込んだ後にリグレッションテストを行うだけでよく、
また、stagingにマージしてしまったものをRevertすることもかなり減ったため、こうした作業コストも減りました。

staging環境 ≒ 本番環境ではなかった

本番環境での不具合が起きたときなど、すぐにstaging環境で動作確認ができるようになりました。

これまでもできてはいましたが、stagingブランチとmainブランチとの差分がどこにあるのかを把握する必要があり、多少の工数が発生していました。

おわりに

最後までお読みいただきありがとうございました。

今回は、元々のフローを踏襲する形で変更しました。

この記事を書くにあたり、別チームのリードエンジニアにレビューいただいたところ、
ブランチを増やすのではなく、タグを打つことをHookしてデプロイする方が、ブランチの数も増えず運用が楽かも？と別の方法も教えてもらいました。

しばらくは変更後のフローで運用して、
運用する上で課題が見つかったときに、別の方法も検討してみたいと思います。（そして記事にします。

おまけ

３つも環境立てられないよ〜の時のGitFeatureFlow図
一応、以下のフローも提案していたので載せておきます。

参考

Gitの運用フローを考える上で参考にさせていただいた記事です。