バイセル Tech Blog

バイセル Tech Blogは株式会社BuySellTechnologiesのエンジニア達が知見・発見を共有する技術ブログです。

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

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

背景

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

tech.buysell-technologies.com

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

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

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

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

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

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

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

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

方針

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

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

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

f:id:bst-tech:20201211215142p:plain

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

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

f:id:bst-tech:20201211215219p:plain

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

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

実践

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

f:id:bst-tech:20201211215304p:plain

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

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

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

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

半年間運用して

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

まとめ

年の瀬ということで、マイクロサービスのバージョン管理について書かせていただきました。 バージョンアップってレベルアップ感があっていいですよね w

今年一年で、弊社のテックメンバーもガンガンバージョンが上がっていて、組織全体での成長を感じます。 個々のメンバの成長が影響を与えあって、全体が成長する。そういった意味でも、組織はマイクロサービスのようですね ^^

バイセルテクノロジーズでは、共にバージョンアップしていけるエンジニアを募集しています。