依存関係地獄におさらば〜マイクロサービスのバージョン管理について〜

テクノロジー戦略本部の和田です。もうすぐ 2020年も終わりですね。年の変わりって、メジャーバージョンのアップデートに似ている気がしませんか？というわけで、今回は、弊社で運用中のマイクロサービスのバージョン管理の話をしたいと思います。

背景

弊社では今年、基幹システムを自社開発したシステムに切り替えました。このシステムは GKE 上にマイクロサービスとして構築されています。そのアーキテクチャについては、弊社村上の記事をご覧ください。

記事にあるように、システムは複数のバックエンドサービス・BFF・Web Frontend・iOS アプリなどで構成されています。そして、それぞれが異なる GitHub リポジトリで管理されており、下記のようなデプロイのパイプラインが組まれています。

develop ブランチへの push で、dev 環境へデプロイ
master ブランチへの push で、staging 環境へデプロイ
ver_*.*.* タグへの push で production 環境へデプロイ

GitHub ドリブンいいですよね！もう昔のように、踏み台経由してデプロイサーバに入って rsync なスクリプトを叩くことはありませんね！（懐

ですが、リリース前、production 環境の整備が終わった頃に思ったわけです。あれ、えーっと、この production リリース用のタグのバージョン、どうやって付けよう・・

各リポジトリで、フランクにセマンティックバージョニングに従ってバージョンをつけることもできます。ただ、10人ほどのチームで、複数のリポジトリに跨った機能の追加や改善が並走している状況。

リポジトリ毎のバージョンの依存関係
各環境のバージョンの状態
一部機能のリリース延期などのイベント発生

うまくやれる人はいるかもしれない…。でも少なくとも私には無理ー！w というわけで、なるべく楽に、以下を実現できる方法を考えることになりました。

各リポジトリのバージョンの依存関係が簡単に把握できる
新機能開発や hotfix の際に、どのブランチから派生させるかや付けるタグが簡単に決められる

方針

バージョンはシステム全体で一つのシーケンスで管理
隔週でマイナーバージョンを上げる
hotfix のリリース時にパッチバージョンを上げる

バージョンはシステム全体で一つのシーケンスで管理

システムに変更がある場合、システム全体のバージョンを上げます。そして、各リポジトリを production にデプロイする際は、このシステム全体のバージョンをタグにつけます。このようにすると、結果的に依存関係のあるリポジトリの変更は同じバージョンで行うことになるので、システムのバージョンがわかれば、すべてのサービスの依存バージョンが明らかになります。

隔週でマイナーバージョンを上げる

マイナーバージョンのリリース日は、変更の有無に関わらずあらかじめ決めておきます。リリース日が決まっているので、逆算で master ブランチへのマージ日や、staging 環境での UAT の日程も決まります。マイナーバージョンアップで扱う変更は、弊社の基幹業務に影響のあるもののため、このようにすることで、業務の日程調整の手間も減ります。基本的に、master ブランチは現在の production バージョンになっており、develop ブランチは次のマイナーバージョンという扱いになるため、リリースするバージョンが決まれば、派生元のブランチが決まります。隔週なのは、スクラムのスプリント期間と合わせているためです。

hotfix のリリース時にパッチバージョンを上げる

バグFIXや、業務影響のないリリースは CI/CD の設定を生かして、できたものからガンガンデプロイしていきます。派生元は master ブランチです。

実践

弊社ではタスク管理に Atlassian の Jira を使っています。そのため、システム全体のバージョン管理には Jira のリリース機能を利用しました。

システムに対応する Jira プロジェクトを作成
リリース機能でバージョンを切る
システムの変更を Jira チケットで管理
リリースバージョンが決まったら、チケットの修正バージョンに設定

特に変わった使い方はしていませんね。Jira 上では下記を確認することができます。

バージョンに紐付いたチケットの一覧
チケットで対応した Pull Request や commit の一覧（GitHub 連携）

commit や PR のタイトルに Jira のチケット ID を入れておくことで自動で紐づくのが便利ですね。複数のリポジトリにまたがった変更の場合、対応内容が集約されるので管理もしやすくなります。

半年間運用して

さっき数えてみたら、システムリリースからの約半年で 98 回リリースを行っていました。現在のバージョンは 1.17.1 です。２日に１回の割合でリリースしている計算ですね。CI/CD の恩恵を強く感じます。この期間、依存関係やリリースフローで大きく困ることなかったので、このやり方もとりあえずうまく機能したようで良かったです。