How to Do Stubs versioning?

本节涵盖存根的版本控制，您可以通过多种不同的方式进行处理：

This section covers versioning of the stubs, which you can handle in a number of different ways:

API Versioning

版本控制实际上意味着什么？如果您指的是 API 版本，则有不同的方法：

What does versioning really mean? If you refer to the API version, there are different approaches:

  • Use hypermedia links and do not version your API by any means

  • Pass the version through headers and URLs

我们不会试图回答哪种方法更好。您应该选择适合您需求并让您产生业务价值的方法。

We do not try to answer the question of which approach is better. You should pick whatever suits your needs and lets you generate business value.

假设您确实对 API 进行了版本控制。在这种情况下，您应该提供尽可能多的合同，以及尽可能多的版本。您可以为每个版本创建一个子文件夹，或将其附加到合同名称——以适合您的方式为准。

Assume that you do version your API. In that case, you should provide as many contracts with as many versions as you support. You can create a subfolder for every version or append it to the contract name — whatever suits you best.

JAR versioning

如果您通过版本控制指的是包含存根的 JAR 版本，那么本质上主要有两种方法。

If, by versioning, you mean the version of the JAR that contains the stubs, then there are essentially two main approaches.

假设您确实实施了持续交付和部署，这意味着每次您通过管道时都会生成一个新版本的 jar，并且 jar 可以随时投入生产。例如，您的 jar 版本如下所示（因为它是在 20.10.2016 的 20:15:21 生成的）：

Assume that you do continuous delivery and deployment, which means that you generate a new version of the jar each time you go through the pipeline and that the jar can go to production at any time. For example, your jar version looks like the following (because it got built on the 20.10.2016 at 20:15:21) :

1.0.0.20161020-201521-RELEASE

在这种情况下，您生成的存根 jar 应该如下所示：

In that case, your generated stub jar should look like the following:

1.0.0.20161020-201521-RELEASE-stubs.jar

在这种情况下，您应该在引用存根时在 application.yml 或 @AutoConfigureStubRunner 内提供最新版本的存根。您可以通过加上“+”符号来实现。以下示例展示了如何操作：

In this case, you should, inside your application.yml or @AutoConfigureStubRunner when referencing stubs, provide the latest version of the stubs. You can do that by passing the + sign. the following example shows how to do so:

@AutoConfigureStubRunner(ids = {"com.example:http-server-dsl:+:stubs:8080"})

但是，如果版本控制是固定的（例如 1.0.4.RELEASE 或 2.1.1），则必须设置 jar 版本的具体值。以下示例展示了如何对版本 2.1.1 进行操作：

If the versioning, however, is fixed (for example, 1.0.4.RELEASE or 2.1.1), you have to set the concrete value of the jar version. The following example shows how to do so for version 2.1.1:

@AutoConfigureStubRunner(ids = {"com.example:http-server-dsl:2.1.1:stubs:8080"})

Development or Production Stubs

您可以操作分类器，以针对其他服务或已部署到生产环境的存根的当前开发版本运行测试。如果您在达到生产部署后将构建更改为使用 prod-stubs 分类器部署存根，那么您可以同时针对开发存根和生产存根运行测试。

You can manipulate the classifier to run the tests against the current development version of the stubs of other services or the ones that were deployed to production. If you alter your build to deploy the stubs with the prod-stubs classifier once you reach production deployment, you can run tests in one case with development stubs and in another case with production stubs.

以下示例适用于使用存根的开发版本的测试：

The following example works for tests that use the development version of the stubs:

@AutoConfigureStubRunner(ids = {"com.example:http-server-dsl:+:stubs:8080"})

以下示例适用于使用存根的生产版本的测试：

The following example works for tests that use the production version of stubs:

@AutoConfigureStubRunner(ids = {"com.example:http-server-dsl:+:prod-stubs:8080"})

您还可以在部署管道中从属性中传递这些值。

You can also pass those values also in properties from your deployment pipeline.