Spring Cloud Contract 爬坑记

前言：spring-cloud-starter-contract-verifier:2.1.1.RELEASE.

spring-cloud-contract-maven-plugin:2.2.1.RELEASE.

spring-cloud-starter-contract-stub-runner:2.1.1.RELEASE.

我的项目是maven项目，groovy写的contract.

这里不会涉及怎么搭建和使用。网上已经有很多这种例子。假设读者已经具有Spring cloud contract的知识，建议用最新的版本，以前有人说用旧版本会比较稳定，我看这个spring cloud contract旧的版本不稳定呀。如果你是在用的时候遇到问题，估计我下面的内容应该可以解决到你的问题。下面是我爬坑记。

对于Producer：

我自己是用groovy写的contract.写完contract.还有BaseClass，你会在pom文件里面写上贴上你的BaseTestClass

          <plugins><plugin><groupId>org.springframework.cloud</groupId><artifactId>spring-cloud-contract-maven-plugin</artifactId><version>2.1.1.RELEASE</version><extensions>true</extensions><configuration><baseClassForTests>com.example.contractTest.BaseTestClass</baseClassForTests> </configuration></plugin></plugins>

import org.springframework.cloud.contract.spec.ContractContract.make {request {method('PUT')headers {contentType(applicationJson())}body(file("request.json"))url("/1")}response {status OK()body(file("response.json"))headers {contentType(applicationJson())}}
}

上面那段配置我贴官网的。在生成stub包的时候，你会发现有一个类叫ContractVerifierTest，这个是用来验证你的contract,它会继承BaseTestClass，所以当你的build失败，你打开ContractVerifierTest，debug里面的test case，然后就知道哪里有问题了。如果你的Contract里面的response body用了file 指向一个json文件，那么生成出来的 ContractVerifierTest对应的test case是没有response的字段校验的，所以你的响应数据要谨慎喔，这是小细节，你可以自己在ContractVerifierTest加校验，但是小心重新生成被覆盖。

干货来了，如果你在本地推你的contract到github的时候，如果你是用ssh的，但是又Auth Fail的字眼出现，这时你要检查你生成的公钥的时候是不是要输入密码的，如果你git clone代码的时候每次都要你输入密码，那就是这个问题所在的，你在生成密钥的时候不要输入密码直接回车过去就可以了。然后还是不行，那就用stackoverflow上面说的在你的git bash执行下面指令。这样应该可以过去了，我就是这样子过来的，我当初直接执行这个bash 脚本，不成功呀。就是因为设置了私钥的密码。如果你不用ssh当然你也可以用https形式推到github上面去，但是你要配置了<contractsRepositoryUsername>和<contractsRepositoryPassword>，下面是spring-cloud-contract-maven-plugin的配置你值得收藏。如果你用百度搜索你会很容易GG的，建议用bing，能健康上网，那当然用google。

https://cloud.spring.io/spring-cloud-contract/spring-cloud-contract-maven-plugin/

# to run the agent
$ eval `ssh-agent`
#to store the pass in the agent
ssh-add ~/.ssh/id_rsa

<!--这个配置是推到github仓库-->
<plugin><groupId>org.springframework.cloud</groupId><artifactId>spring-cloud-contract-maven-plugin</artifactId><version>${spring-cloud-contract.version}</version><extensions>true</extensions><configuration><!-- Base class mappings etc. --><!-- We want to pick contracts from a Git repository --><contractsRepositoryUrl>git://git@github.com:spring-cloud-samples/spring-cloud-contract-nodejs-contracts-git.git</contractsRepositoryUrl><!-- We reuse the contract dependency section to set up the pathto the folder that contains the contract definitions. In our case thepath will be /groupId/artifactId/version/contracts --><contractDependency><groupId>${project.groupId}</groupId><artifactId>${project.artifactId}</artifactId><version>${project.version}</version></contractDependency><!-- The contracts mode can't be classpath --><contractsMode>REMOTE</contractsMode></configuration><executions><execution><phase>package</phase><goals><!-- By default we will not push the stubs back to SCM,you have to explicitly add it as a goal --><goal>pushStubsToScm</goal></goals></execution></executions>
</plugin>

Producer你以为我已经结束了？还没有，在我推的那一刻，我发现还是失败了，报出generateTests failed: No stubs or contracts were found for[xxx]: and the switch to fail on no stubs was set.当我看到这个的时候，我内心是十万只草泥马。我看了一下日志，什么，他会去github上面拉代码，报了个can not access.原因是什么？下面是我的猜想，就git上面对应的版本号没有这个contract，所以他在download下来的时候报错，所以我用了另外一个方法，我先把stub包生成出来然后再执行pushStubsToScm goal,这个在maven插件Plugins下面会有。那生成的时候肯定不能用上面的配置，要换成推上nexus的那种配置生成stub。在你的github仓库有了你相对应版本的contract的时候，你就可以用上面github的配置了。

<!--这个配置是推到Nexus-->
<plugin><groupId>org.springframework.cloud</groupId><artifactId>spring-cloud-contract-maven-plugin</artifactId><version>${spring-cloud-contract.version}</version><extensions>true</extensions><configuration><baseClassForTests>com.example.contractTest.BaseTestClass</baseClassForTests> </configuration>
</plugin>

Consumer端：

如果是使用REMOTE模式，你要在你的项目配置账号和密码，这样是不是很坑。这样安全吗，如果公司不考虑安全直接可以上，但是我公司不行呀，这样搞肯定不行啊，那他可读external的setting.xml文件吗，在社区上面还是一个被mark成enhancement。我也有曾想过encrypt，加密了放在那里，但是你总会有做解密的地方，java反编译，什么都看出来了。但是如果你公司不care，那没有关系的。直接在你properties文件配置stubrunner.username .stubrunner.password。还有一点，你的密码有没有过期的时候呢。

最后我想出了一个解决方案：就是直接在maven 里面把stub包加入成为依赖<scope>为test。然后运行模式换成CLASSPATH.哈哈这样就可以了吧，这里要注意stub包的版本要最新的，不然别人改了接口，重新发布，你拿的还是旧的contract，上生产的时候你就GG了，不过这样通常在做联调测试的时候会被发现。要是没发现那真的是GG了。怎么保持stub版本最新，这里运用到maven version的版本控制的小技巧， <version>LATEST</version>,我就让他拿最新的，当然你也可以控制他只拿[1,+)即>=1.0的版本。这个方案有不好地方，就是依赖了很多无用的包进来项目，如果contract太多会导致包臃肿过大，还会有包的冲突的问题。要自己去exclude。

最后：我是采取producer推上nexus，consumer在pom文件引入依赖的方式进来。原因:解决不用配置用户密码的问题，还有公司环境限制。写contract的时候少在uri用正则表达式，我用的版本如果在uri那里使用了正则，然后consumer端若对应的uri参数有问题会直接匹配到了actuator的/health,比较难找出问题。

Spring Cloud Contract 爬坑记相关推荐

spring cloud contract的应用实现与概念理解-服务请求者一侧的落地-细节较多避免踩坑卡壳
笔者的经验认为,微服务的出现,是为了应对传统SOA架构在多服务背景下的疲软,本质上是SOA的进一步衍生.是一种治理服务的手段.而微服务之所以能够解决传统SOA.单块大单体程序的问题,原因在于微服务自身 ...
spring cloud contract的应用实现与概念理解-服务提供者一侧的落地
如题,本文是在前一篇"spring cloud contract的应用实现与概念理解-服务请求者一侧的落地"的基础上,续写服务提供者一侧的有关实现与理解. 通过对官网文章的学习和编 ...
Marcin Grzejszczak访谈：Spring Cloud Contract
Marcin Grzejszczak是Pivotal的一名软件工程师.目前,他在从事Spring Cloud Contract的开发,这是一个消费者驱动的.面向Java的契约框架.为了了解该框架的一些 ...
Spring Cloud Contract 契约测试实践
本文转载公众号:永辉云创技术该号由我参与维护,欢迎大家关注支持!!! 分布式研发模型演进众所周知, 分布式系统是由众多微服务构成,并按照功能模块划分后, 由不同的开发小组进行维护. 研发模型如下图 ...
消费者驱动的微服务契约测试套件：Spring Cloud Contract
在微服务架构下,你的服务可能由不同的团队提供和维护,在这种情况下,接口的开发和维护可能会带来一些问题,比如服务端调整架构或接口调整而对消费者不透明,导致接口调用失败. 为解决这些问题,Ian Robi ...
消费者驱动的微服务契约测试套件Spring Cloud Contract
在微服务架构下,你的服务可能由不同的团队提供和维护,在这种情况下,接口的开发和维护可能会带来一些问题,比如服务端调整架构或接口调整而对消费者不透明,导致接口调用失败. 为解决这些问题,Ian Robi ...
消费者驱动的契约测试 Spring Cloud Contract介绍
消费者驱动的契约测试 Spring Cloud Contract介绍什么是契约测试测试是软件流程中非常重要,不可或缺的一个环节.一般的测试分为单元测试,集成测试,端到端的手工测试,这也是构成测试金 ...
我在「小米爬坑记」里，看到的 3 个创业真相
小米把10年的创业经历,做了一次「开源」. 就在昨晚,雷军做了小米十周年的公开演讲.在演讲中,雷军对小米10年的发展做了一次大梳理,既有成绩,也有反思,还有小米历史上一些非常关键的发展节点.其实上个月 ...
Spring Cloud Contract实践
1.Spring Cloud Contract简介 Spring Cloud Contract是一个总体项目,其中包含帮助用户成功实施消费者驱动合同方法的解决方案.目前,Spring Cloud Co ...

Spring Cloud Contract 爬坑记

Spring Cloud Contract 爬坑记相关推荐

最新文章

热门文章