如何进行 Stubs 版本控制？

版本控制到底意味着什么？如果您指的是 API 版本，有几种不同的方法

我们不试图回答哪种方法更好的问题。您应该选择最适合您的需求并能为您带来商业价值的方法。

假设您确实对 API 进行了版本控制。在这种情况下，您应该为您支持的每个版本提供相应的契约。您可以为每个版本创建一个子文件夹，或者将其附加到契约名称中——选择最适合您的方法。

如果版本控制指的是包含 Stub 的 JAR 的版本，那么主要有两种方法。

假设您进行持续交付和部署，这意味着每次通过管道时都会生成一个新的 JAR 版本，并且该 JAR 可以随时投入生产。例如，您的 JAR 版本可能看起来像下面这样（因为它是在 2016 年 10 月 20 日 20:15:21 构建的）

在这种情况下，您生成的 Stub JAR 应该看起来像下面这样

在这种情况下，在您的 application.yml 或 @AutoConfigureStubRunner 中引用 Stub 时，您应该提供 Stub 的最新版本。您可以通过传递 + 符号来实现。以下示例展示了如何操作

然而，如果版本控制是固定的（例如，1.0.4.RELEASE 或 2.1.1），您必须设置 JAR 版本的具体值。以下示例展示了如何为版本 2.1.1 执行此操作

您可以操作 classifier 以针对其他服务的当前开发版本 Stub 或已部署到生产环境的 Stub 运行测试。如果您修改构建过程，在达到生产部署阶段时使用 prod-stubs classifier 部署 Stub，那么您可以在一种情况下使用开发环境 Stub 运行测试，在另一种情况下使用生产环境 Stub 运行测试。

以下示例适用于使用开发版本 Stub 的测试

以下示例适用于使用生产版本 Stub 的测试

您也可以从部署管道通过属性传递这些值。