API版本控制
让我们尝试回答一个真正意义上的版本控制的问题。如果你指的是API版本，那么有不同的方法。
使用超媒体，链接，不要通过任何方式版本您的API
通过标题/网址传递版本
我不会试图回答一个方法更好的问题。无论适合您的需求，并允许您创造商业价值应被挑选。
假设你做你的API版本。在这种情况下，您应该提供与您支持的许多版本一样多的合同。您可以为每个版本创建一个子文件夹，或将其附加到合同名称 - 无论如何适合您。
JAR版本控制
如果通过版本控制是指包含存根的JAR的版本，那么基本上有两种主要方法。
假设您正在进行连续交付/部署，这意味着您每次通过管道生成新版本的jar时，该jar可以随时进行生产。例如你的jar版本看起来像这样（它建立在20.10.2016在20:15:21）：
1.0.0.20161020-201521-RELEASE
在这种情况下，您生成的存根jar将看起来像这样。
1.0.0.20161020-201521-RELEASE-stubs.jar
在这种情况下，您应该在application.yml或@AutoConfigureStubRunner内引用存根提供最新版本的存根。您可以通过传递+号来做到这一点。例
@AutoConfigureStubRunner(ids = {"com.example:http-server-dsl:+:stubs:8080"})
如果版本控制是固定的（例如1.0.4.RELEASE或2.1.1），则必须设置jar版本的具体值。示例2.1.1。
@AutoConfigureStubRunner(ids = {"com.example:http-server-dsl:2.1.1:stubs:8080"})
开发者或生产者存根
您可以操作分类器，以针对其他服务的存根或部署到生产的存根的当前开发版本来运行测试。如果您在构建生产部署之后，使用prod-stubs分类器来更改构建部署，那么您可以在一个案例中使用dev stub运行测试，另一个则使用prod stub进行测试。
使用开发版存根的测试示例
@AutoConfigureStubRunner(ids = {"com.example:http-server-dsl:+:stubs:8080"})
使用生产版本的存根的测试示例
@AutoConfigureStubRunner(ids = {"com.example:http-server-dsl:+:prod-stubs:8080"})
您也可以通过部署管道中的属性传递这些值。
共同回购合同
存储合同以外的另一种方法是将它们保存在一个共同的地方。它可能与消费者无法克隆生产者代码的安全问题相关。另外，如果您在一个地方保留合约，那么作为生产者，您将知道有多少消费者，以及您的本地变更会消费哪些消费者。
回购结构
假设我们有一个坐标为com.example:server和3个消费者的生产者：client1，client2，client3。然后在具有常见合同的存储库中，您将具有以下设置（您可以在此处查看：
├── com
│ └── example
│ └── server
│ ├── client1
│ │ └── expectation.groovy
│ ├── client2
│ │ └── expectation.groovy
│ ├── client3
│ │ └── expectation.groovy
│ └── pom.xml
├── mvnw
├── mvnw.cmd
├── pom.xml
└── src
└── assembly
└── contracts.xml
您可以看到下面的斜线分隔的groupid/工件id文件夹（com/example/server），您对3个消费者（client1，client2和client3）有期望。期望是本文档中描述的标准Groovy DSL合同文件。该存储库必须生成一个将一对一映射到回收内容的JAR文件。
server文件夹内的pom.xml示例。
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
你可以看到除了Spring Cloud Contract Maven插件之外没有依赖关系。这些垃圾是消费者运行mvn clean install -DskipTests来本地安装生产者项目的存根的必要条件。
根文件夹中的pom.xml可以如下所示：
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
它正在使用程序集插件来构建所有合同的JAR。此类设置的示例如下：
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.3 http://maven.apache.org/xsd/assembly-1.1.3.xsd">
工作流程
工作流程将与Step by step guide to CDC中提供的工作流程类似。唯一的区别是生产者不再拥有合同。所以消费者和生产者必须在共同的仓库中处理共同的合同。
消费者
当消费者希望脱机工作，而不是克隆生产者代码时，消费者团队克隆了公用存储库，转到所需的生产者的文件夹（例如com/example/server），并运行mvn clean install -DskipTests在本地安装存根从合同转换。
提示您需要在本地安装Maven
制片人
作为一个生产者，足以改变Spring Cloud Contract验证器来提供包含合同的URL和依赖关系：
使用此设置，将从http://link/to/your/nexus/or/artifactory/or/sth下载具有groupidcom.example.standalone和artifactidcontracts的JAR。然后将在本地临时文件夹中解压缩，并将com/example/server下的合同作为用于生成测试和存根的选择。由于这个惯例，生产者团队将会知道当一些不兼容的更改完成时，哪些消费者团队将被破坏。
其余的流程看起来是一样的。