『数据库』微服务化的基石——持续集成( 四 ) |Java|美好，一直

数据库设计是否合理

数据库事务是否使用合理

代码是否有明显的阻塞

代码审核完毕之后提交上去之后，一个是要通过静态代码审查，可以发现一些可能带来代码风险的问题，例如异常过于宽泛等。
在就是要通过单元测试。我们应该要求每个类都要有单元测试，并且单元测试覆盖率要达到一定的指标。单元测试要有带Mock的模块内的集成测试。
在编译过程中会触发单元测试，单元测试不通过，已经代码覆盖率，都会统计后发邮件，抄送所有的人，这对于研发来讲又是一个压力。
当有一天你的提交break掉了测试，或者代码覆盖率很低，则就像通报批评一样，你需要赶紧去修改。
单元测试完毕之后，就会上传成果物，或者是war或者是jar ，一般会用nexus ，因为有版本号，有md5 ，可以保证安装在环境中的就是某个版本的某个包，我们还遇到过有使用FTP的，这样一个是很难保证版本号的维护，升级和回滚比较难弄，另一个是没有md5 ，很可能包不完整都有可能的，而且一旦发生，很难发现。
如果使用了容器，则还需要编译Dockerfile ，使用Docker镜像作为交付，能够实现更好的环境一致性，保证原子的升级和回滚。
每天下班前，当天的代码需要提交到库中去，晚上会做一次统一的环境部署和集成测试。
每天晚上凌晨，会有自动化的脚本将Docker镜像通过编排部署一个完整的环境，然后跑集成测试用例，集成测试用例应该是基于API的，很多的公司是基于UI的，这样由于UI变化太快，还有UI不能覆盖所有的场景，所以还是建议UI和API分离，通过API进行集成测试，有了每天的测试，才能保证每天晚上的版本都是可以交付的版本，也保证我们微服务拆分的时候，尽管改了很多，不会因为新的修改，破坏掉原来能够通过的测试用例，保证不会有了新的，坏了旧的。
这个集成测试或者叫回归测试每天晚上都做，都是在一个全新的环境中，这就是持续部署和持续交付。
如果某一天测试不通过，则会发出邮件来，是因为当天谁的哪个提交，导致测试不通过，抄送所有人，这是另一个压力。
所以第二天的站会上，昨天你完成了哪些功能，是否提交了，是否完成了单元测试，是否通过了集成测试，就都知道了，你需要给大家一个解释，然后进入到新一天的开发。
到了两周，一个周期完毕，可以上线到生产环境了，可以通知有权限的运维进行操作，但是也是通过自动化的脚本进行部署的。
这就是整个过程，层层保证质量，从中可以看到，敏捷开发，持续集成，持续交付，持续部署， DevOps是互相联系的，少了任何一个，整个流程都玩不转。
五、有关代码结构代码结构往往包括：

API接口包
访问外部服务包
数据库DTO
访问数据库包
服务与商务逻辑
外部服务

如果使用Dubbo RPC ，则API接口往往在一个单独的jar里面，被服务端和客户端共同依赖，但是使用了springcloud的restful方式就不用了，只要在各自的代码里面定义就可以了，会变成json的方式传递，这样的好处是当jar有多个版本依赖，需要升级的时候，关系非常复杂，难以维护，而json的方式比较好的解决了这个问题。
这个模块提供了哪些接口，只要到API接口这个package下面找就可以了。因为无论是Dubbo还是springcloud ，接口的调用都会重试，因而接口需要实现幂等。
访问外部服务的包，这将所有对外的访问独立出来，好处一是可以抽象出来，在服务拆分的时候，可能会用到，例如原来支付的逻辑在下单的模块中，要讲支付独立出来，则会有一个抽象层，涉及到老的支付方式，还是调用本模块中的逻辑，涉及到新接入的支付方式使用远程调用，有了这一层方便的多。好处二是可以实现熔断，当被调用的服务不正常的时候，在这里可以返回托底数据。好处三是可以实现Mock ，这样对于单元测试来讲非常好，不用依赖于其他服务，就可以自己进行测试。