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>
