web-dev-qa-db-ja.com

製品のバージョニングマイクロサービス

私はdockerに基づいたマイクロサービスアーキテクチャに取り組み、3つのマイクロサービスを使用して、たとえば「CRMシステム」などの1つの製品を作成します。

今、私はクライアントが望むときにいつでも彼の製品をアップグレードできるようにしたいと思っています。私のマイクロサービスには3つの異なるバージョンがありますが、クライアントはどれを見る必要がありますか？マイクロサービスバージョンの1つをコピーすると、バージョンがない場合よりもトラブルが発生するため、製品バージョンはマイクロサービスから独立している必要があると思います。

だから、そのような状況に対処するためのパターン、アイデアはありますか？

私の頭に浮かぶのは、マイクロサービスの1つが本番環境に対応するパッケージを生成するたびにバージョン管理される別のリポジトリを用意することです。ただし、現在、私は製品所有者（PO）の誰も知らないバージョンを持っています。

architecturedockerdomain-driven-designsoamicroservices
22
Dariss

マイクロサービスのバージョニング

まず最初に Semantic Versioning（SemVer） の後にマイクロサービスが厳密に続くことを確認します。これを行わないと、遅かれ早かれ非互換性の問題が発生します。

そのバージョンでのAPIの変更のみをキャプチャし、マイクロサービスの内部バージョン管理（DBを持つサービスのDBスキーマのバージョン管理など）と混同しないでください。

製品のバージョン管理

すでに提案したように、製品のバージョンを紹介します。ここでもSemVerをフォローすることは理にかなっていますが、マーケティングのニーズを満たすために緩める必要がある場合があります（たとえば、SemVerはマイナーバージョンのインクリメントしか必要としない場合でも、メジャーバージョンのインクリメントを許可できます）。極端な場合は、専用の「技術バージョン」と「マーケティングバージョン」を使用してください。ただし、これは顧客にとってもより複雑です。

また、アプリケーション全体には「API」がないため、アプリケーションの観点からSemVerバージョンの意味を定義する必要があることにも注意してください。

依存関係管理

現在、特定の製品バージョンは、特定のバージョンのマイクロサービスのリストです。これは本質的に、apt、npm、bowerなどが実装するのと同じ意味での依存関係管理であることに注意してください。ソリューションをどの程度高度にする必要があるかを言うのは難しいですが、少なくとも「最低限必要なバージョン」の概念をサポートすることをお勧めします。 dockerに組み込みメカニズムがある場合は、それを使用してみてください（私はdockerをよく知らないので、わかりません）。

これで、あなたは例えばです。バージョン4.8.12の製品がバージョン1.12.0のサービスAと3.0.4のサービスBを必要とすることを指定できます。

更新メカニズムは、SemVerに準拠した戦略に従う必要があります。つまり、特定の製品バージョンをインストールすると、最新のサービス同じメジャーバージョンを使用が自動的にインストールされます。上記の例では、これは例えばサービス1.12.2とサービスBの3.3.0をインストールします。依存関係の要件を満たす、すでにインストールされているサービスを維持するメカニズムを提供することは、ユーザーが更新メカニズムに煩わされないようにするために良い考えです。 。

19
theDmi

文献ではこれに5次元モデルを使用しています。

  • バージョン（変更したい）
  • ステータス（ライフサイクル：作成、テスト、デプロイ、廃止）
  • 表示（ソース、デプロイメント、ドキュメント）
  • 階層（製品、マイクロサービス）
  • バリアント（ほぼ同じ、相違点、製品ファミリを説明）

ほとんどのシステムは、これらの次元のいくつかしか処理しません。 5つすべてを処理するには、開発プロセスを説明（修正）する必要があります。

バージョンと階層のみを見る場合、ここでは製品とマイクロサービスを別々にバージョン管理する場合と同じように、製品のユーザーが別の何かに気付くとすぐに製品のバージョンを変更する必要があります。メジャー-マイナー番号付けを使用して、マイクロサービスのバージョン管理からそれを通知することができます。または、バージョン範囲/セマンティックバージョニングを使用できます。

参照：

設計データの管理：CAD=フレームワーク、構成管理、および製品データ管理の5つの側面。vanden Hamer、P。Lepoeter、K。Philips Res。、Eindhoven;

このペーパーは、IEEE発行日：1996年1月巻：84、号：1ページに掲載：42-56 ISSN：0018-9219引用文献：26 CODEN：IEEPAD INSPECアクセッション番号：5175049 Digital Object Identifier ：10.1109/5.476025現在のバージョン公開日：2002-08-06

4
Stephan Eggermont