微服务的持续集成，四步“构建”一个代码世界

本文转自微信号EAWorld。扫描下方二维码，关注成功后，回复“普元方法+”，将会获得热门课堂免费学习机会！

大师Martin Fowler对持续集成是这样定义的：持续集成是一种软件开发实践，即团队开发成员经常集成他们的工作，通常每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建（包括编译，发布，自动化测试)来验证，从而尽快地发现集成错误。

今天我们就来聊一聊微服务的持续集成。

目录

一、持续集成之构建
二、持续集成之部署
三、持续集成之测试
四、持续集成之发布
五、总结

一、持续集成之构建

---

当微服务产生后，持续集成也不得不考虑起针对这种可以独立部署的服务，当有十多个微服务同时运行甚至更多的时候，如何建立起与之的映射，即微服务、CI构建与源码的映射变得极为重要，如果还像简单软件那样集中管理是否还行得通，那可能会是一场灾难？在如此复杂的背景下，优良的持续集成方案同样也会给我们带来焕然一新的便利体验。

在此，我们就先了解下微服务架构下的三种持续集成构建模式。

1. 一个代码库、一个CI构建

这种方式就是将所有的微服务放在同一个代码库中，并且使用一个CI构建。这么做唯一的好处就是只需要管理一个代码库，但随之而来的麻烦会让你应接不暇。每当我们修改一个服务中的一行代码后，我们必须重新构建所有的服务，所有的构建产物都是在同一个构建中完成。

事实上其他的服务完全没有重新构建的必要，这样大大延长了上线速度。而在众多构建物中要找出保证能够让你修改生效的服务来部署，也是足够让人头疼了，这导致最终让我们选择重新部署所有代码。再试想一下，所有人共享一个CI构建，每个人的修改都有可能造成CI的构建失败，想要将这个CI构建成功稳定下来，头痛又升级了。

在众所周知的谷歌使用的就是一个代码库，然而他们采用了自己的版本管理系统“piper”来管理超过20亿行代码的超级大库，所以对于更多的小公司来说，谷歌就是一个特例。

2.一个代码库、多个CI构建

在这种方式中，代码库还是那个代码库，不过在代码库中我们创建了多个子目录，每个子目录对应一个CI构建。现在的很多项目中都会采取这种持续集成，这让我们可以比较方便的同时提交对多个服务的修改。

然而，来让我们琢磨一下这种方式依旧会存在的弊端，随着代码修改的增加，无可避免的会在不经意间造成服务耦合度的增加，当部分代码出现问题的时候受到影响的很可能是多个构建。

3.