How to Do Stubs versioning?

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

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

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

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

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

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

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

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

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

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

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

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