スタブのバージョン管理を行うにはどうすればよいですか ?

バージョン管理とは実際には何を意味しますか ? API バージョンを参照すると、さまざまなアプローチがあります。

どのアプローチがより優れているかという質問には答えようとはしません。自分のニーズに合った、ビジネス価値を生み出すことができるものを選択する必要があります。

API のバージョン管理を行うと仮定します。その場合、サポートするのと同じ数のバージョンの契約をできるだけ多く提供する必要があります。バージョンごとにサブフォルダーを作成することも、契約名にサブフォルダーを追加することもできます。最適なものを選択してください。

バージョン管理がスタブを含む JAR のバージョンを意味する場合、基本的に 2 つの主なアプローチがあります。

継続的デリバリーと デプロイを実行するとします。これは、パイプラインを通過するたびに jar の新しいバージョンを生成し、jar がいつでも運用環境に移行できることを意味します。例: jar バージョンは次のようになります (20:15:21 で 20.10.2016 上にビルドされているため)。

その場合、生成されたスタブ jar は次のようになります。

この場合、スタブを参照するときに application.yml または @AutoConfigureStubRunner 内でスタブの最新バージョンを提供する必要があります。+ 標識を通過することでそれを行うことができます。次の例は、その方法を示しています。

ただし、バージョン管理が固定されている場合 (たとえば、1.0.4.RELEASE または 2.1.1)、jar バージョンの具体的な値を設定する必要があります。次の例は、バージョン 2.1.1 でこれを行う方法を示しています。

分類子を操作して、他のサービスのスタブの現在の開発バージョンまたは運用環境にデプロイされたスタブに対してテストを実行できます。本番環境 デプロイに達した後で、prod-stubs 分類子を使用してスタブをデプロイするようにビルドを変更すると、あるケースでは開発スタブを使用してテストを実行し、別のケースでは本番スタブを使用してテストを実行できます。

次の例は、開発バージョンのスタブを使用するテストで機能します。

次の例は、本番バージョンのスタブを使用するテストで機能します。

これらの値を デプロイパイプラインのプロパティに渡すこともできます。