本文转自微信号EAWorld。扫描下方二维码,关注成功后,回复“普元方法+”,将会获得热门课堂免费学习机会!
大师Martin Fowler对持续集成是这样定义的:持续集成是一种软件开发实践,即团队开发成员经常集成他们的工作,通常每个成员每天至少集成一次,也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建(包括编译,发布,自动化测试)来验证,从而尽快地发现集成错误。
今天我们就来聊一聊微服务的持续集成。
目录
一、持续集成之构建
二、持续集成之部署
三、持续集成之测试
四、持续集成之发布
五、总结
一、持续集成之构建
当微服务产生后,持续集成也不得不考虑起针对这种可以独立部署的服务,当有十多个微服务同时运行甚至更多的时候,如何建立起与之的映射,即微服务、CI构建与源码的映射变得极为重要,如果还像简单软件那样集中管理是否还行得通,那可能会是一场灾难?在如此复杂的背景下,优良的持续集成方案同样也会给我们带来焕然一新的便利体验。
在此,我们就先了解下微服务架构下的三种持续集成构建模式。
1. 一个代码库、一个CI构建
这种方式就是将所有的微服务放在同一个代码库中,并且使用一个CI构建。这么做唯一的好处就是只需要管理一个代码库,但随之而来的麻烦会让你应接不暇。每当我们修改一个服务中的一行代码后,我们必须重新构建所有的服务,所有的构建产物都是在同一个构建中完成。
事实上其他的服务完全没有重新构建的必要,这样大大延长了上线速度。而在众多构建物中要找出保证能够让你修改生效的服务来部署,也是足够让人头疼了,这导致最终让我们选择重新部署所有代码。再试想一下,所有人共享一个CI构建,每个人的修改都有可能造成CI的构建失败,想要将这个CI构建成功稳定下来,头痛又升级了。
在众所周知的谷歌使用的就是一个代码库,然而他们采用了自己的版本管理系统“piper”来管理超过20亿行代码的超级大库,所以对于更多的小公司来说,谷歌就是一个特例。
2.一个代码库、多个CI构建
在这种方式中,代码库还是那个代码库,不过在代码库中我们创建了多个子目录,每个子目录对应一个CI构建。现在的很多项目中都会采取这种持续集成,这让我们可以比较方便的同时提交对多个服务的修改。
然而,来让我们琢磨一下这种方式依旧会存在的弊端,随着代码修改的增加,无可避免的会在不经意间造成服务耦合度的增加,当部分代码出现问题的时候受到影响的很可能是多个构建。
3.