【TECH BLOG】GitHub Flow with GitOpsの導入

はじめに

こんにちは、計測プラットフォーム開発本部SREブロックの近藤です。普段はZOZOMATやZOZOGLASS、ZOZOFITなどの計測技術に関わるシステムの開発、運用に携わっています。

計測プラットフォーム開発本部では、複数のプロダクトを開発運用していますが、リリース作業はプロダクト単位で行っています。プロダクトによってローンチから数年経過し安定傾向のものもあれば、ローンチしたばかりで機能開発が盛んなものもある状態です。

複数のプロダクトを管理する上では当然の状況ですが、プロダクト単位でリリース作業手順が異なり、手順そのものにも課題がある状態でした。

本記事では、リリース作業で課題となっていた部分の紹介と、それぞれの課題に対する対応策についてご紹介します。

はじめに
目次
現状
課題と対応方針
- リリース作業の自動化
- リリース作業の自動化をする上での必須条件の確認
- 自動化が必要な箇所の洗い出し
- 自動化対応リリースアナウンス
- 負荷試験の結果確認
- CIが通過した場合、PRのマージ
- BotUserが作成するPRの自動マージを有効化
- ImageUpdaterが作成するPRの自動マージを有効化
- 負荷試験が成功した際に自動マージを有効化する
- リリース粒度のミニマム化
- リリース手順、ブランチ戦略の統一
振り返り
- 導入効果
- 導入後に顕在化した課題
終わりに

現状

これまであった課題をお話しする前に、現状のプロダクト毎のデプロイ方法、ブランチ戦略、リリース頻度をご紹介します。

上記の3つのプロダクトで、デプロイ方法は統一されていますが、ブランチ戦略が異なるため、リリース手順が微妙に異なる状態でした。

ブランチ戦略は昨年から新しいプロダクトはGitHub Flow、それ以前はGit Flowを採用していました。

Git Flowを採用していた背景として、昔は動作確認を手動で行っており、都度のPR単位でリリースすると動作確認の工数がとても高くなる状況でした。このため、リリースを定期作業とすることで作業工数を抑えていた経緯があります。

昨年からデプロイパイプラインのリアーキテクトやArgo Rolloutsの導入なども進み、現状は動作確認やロールバックが自動化されている状態でした。このため、新しいプロダクトではGitHub Flowを採用しています。リリース手順に関しては、GitHubのIssue Templateで管理しており、リリースのタイミングで担当者がIssueを起票していました。

Git FlowとGitHub Flowのブランチ戦略で大きな違いは、GitHub Flowはmainが常にリリース可能な状態であることです。

弊チームで採用していたGit Flowですが、アプリケーションリポジトリではいくつかオリジナルのものに変更を加えてあります。特徴はmainブランチとreleaseブランチという2つのプライマリブランチを保持している点です。developブランチはありません。通常の開発は、releaseブランチからfeatureブランチを作成して行います。リリース作業時はreleaseブランチをmainブランチにmergeし、mainブランチをリリースします。