テクノロジー戦略本部の和田です。もうすぐ 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
です。
2日に1回の割合でリリースしている計算ですね。CI/CD の恩恵を強く感じます。
この期間、依存関係やリリースフローで大きく困ることなかったので、このやり方もとりあえずうまく機能したようで良かったです。
まとめ
年の瀬ということで、マイクロサービスのバージョン管理について書かせていただきました。 バージョンアップってレベルアップ感があっていいですよね w
今年一年で、弊社のテックメンバーもガンガンバージョンが上がっていて、組織全体での成長を感じます。 個々のメンバの成長が影響を与えあって、全体が成長する。そういった意味でも、組織はマイクロサービスのようですね ^^
バイセルテクノロジーズでは、共にバージョンアップしていけるエンジニアを募集しています。 もし興味をお持ちいただけましたらぜひご応募ください! herp.careers