http://www.infoq.com/cn/news/2017/04/spring-cloud-contract

在默认情况下，我们希望用户以JAR文件的形式将生产者存根和契约发布到Maven库。假如存根的组ID为“org.springframework”，工件ID为“spring-boot-application”。为了运行存根，消费者需要像下面这样给测试加上注解：@AutoConfigureStubRunner (ids={'org.springframework:spring-boot-application:+'}

实际情况是，框架会自动下载包含存根的“org.springframework:spring-boot-application” JAR文件的最新版本，然后启动一个内存内HTTP服务器，并在一个随机端口上提供存根。也就是说，只需一条注解，你就可以为构建生成整个环境的存根！此外，真正有趣的是，Spring Cloud Contract可以完全消除服务发现工具。那意味着，存根注册在一个服务注册中心的内存版本中。那样，你可以像使用服务发现那样，向一个真正的HTTP服务器发送一个真正的HTTP请求。

如果你想要在测试环境中对打包好的应用程序执行一些冒烟测试，Spring Cloud Contract的Stub Runner也非常方便。下载好的存根可以注册到真正的服务发现工具中（例如Eureka），在契约中定义的真正的消息可以发送给真正的队列（例如RabbitMQ）。那样，你的应用程序甚至都不知道它在同存根交互。

InfoQ：给我介绍下新的Spring Rest Docs集成吧，它是否可以改变传统的消费者驱动契约工作流？

Grzejszczak：那不新了，不过，它确实获得了更多的关注。有些用户不喜欢编写Groovy DSL，不希望生成测试。他们希望完全属于自己的测试流程。还有一些其他的用户已经在使用Spring Rest Docs测试他们的代码。Dave Syer就是其中的一位用户，向Spring Rest Docs添加Spring Cloud Contract集成就是他的主意。多亏了这个，你才能编写测试来测试你的Web应用程序以及自动生成存根。使用Spring Cloud Contract的最新版本，你还可以从Spring Rest Docs生成Groovy DSL契约。

至于工作流，我可以想象得到，消费者和开发者结对满足消费者需要的测试和存根。那样，流程得以保留。另一方面，有些事情告诉我，Spring Rest Docs方法将更多地应用在“生产者契约”方法中。生产者定义契约是什么样子也是如此。在Spring，我们喜欢用自己的产品来进行开发，Spring Initilizr（start.spring.io背后的代码）已经使用了Spring Cloud Contract，而且，Spring Initilizr存根发布到了Spring的Maven库。

http://www.cnblogs.com/zhangjianbin/p/7567134.html

在CI / CD环境中工作

到目前为止，我们只看到如何在本地机器上开发CDC的新功能。与包/构建管道集成需要更多的调整：

• 默认情况下，生产者的Gradle构建任务将生成并运行合同验证程序测试。它只需要通过添加uploadArchives到其Gradle任务将存根jar发布到远程存储库。
• 该消费者需要配置StubRunner解决存根。这可以通过设置Spring Boot应用程序属性来实现：

stubrunner:

    ids: com.demo:account-service:+:stubs:8082

    repositoryRoot: https://demo.jfrog.io/demo/libs-snapshot</pre>