阿里技术专家:持续交付与微服务背后的实践逻辑(3)
关于代码改动,测试也要跟着改的问题,我想说两点: 第二,要善用IDE帮你做改动.测试代码也是代码,当你修改一个函数签名时,IDE会帮你把所有的调用处都改掉,包括测试代码.所以IDE用得好,修改代码也不是那么痛苦的事情. 那么有了这些测试之后,我应该什么时候运行它们呢.是迭代结束时吗?不!我们应该在每次提交时都完整的运行一遍这些测试.这样一旦出了问题我就可以第一时间知道.这就是持续集成的基本概念. 每次提交代码触发编译、测试、静态检查、打包归档、然后再运行验收测试(AT),然后再部署到类生产环境进行性能测试,再部署到端到端测试环境运行端到端测试.并且把每一步的结果反馈给开发团队. 我们把上图称为持续集成流水线.可以使用很多工具来实现,比如最常见的开源工具Jenkins.或者我目前所负责产品:crp.aliyun.com. 关于更多的持续集成的实践和流水线设计,因为内容很多,这里只讨论几个要点.
我们使用自动化测试加持续集成解决了第一个发布前回归测试耗时的问题. 第二个问题就是:“别人的功能还没做完”.假设现在团队正在进行单分支开发(也就是说所有的功能都提交在一个分支上,不会为了一个功能单独 开出一个长期存在分支).就拿图中红色线这个时间点来讲,第三个需求完成了,业务人员也认为可以做一次发布.但是同时还有另外三个需求正在开发.如果做发布的话,就会把做了一半的东西也给发上去.这是不可以接受的. 解决这个问题有两个思路:那就是功能分支和功能开关. 先看看功能分支: 每开一个新功能,就开一个分支.这个分支存活的时间通常是“周”这个数量级的.哪个功能开发完成了就合入到主干,进行一次发布.这样,其它未完成的功能还没有合入到主干,就不会造成影响.但功能分支有很多的问题,最严重的一个问题是:它和持续集成的理念是冲突的.持续集成是希望你每次提交都能够放在一起进行验证.但使用了分支的话,就只能在合并的时刻,才能真正把所有的东西放在一起进行验证.而这时发现的问题可能一周前已经发生了. 另一个方法,功能开关,会给任何一个新开发的功能在代码级别加上一个开关,使得可以简单的修改一个配置就把一个功能完全隐藏掉.默认所有的开关都是关闭的,如果一个功能做完了,想上,则修改配置,打开开关,进行一次发布即可.听起来很理想,但事实上也需要花费不少的代码来把这件事情真正做好. 关于功能分支和功能开关今天不展开细讲了.有兴趣的朋友可以参看我之前写的一篇文章:http://www.infoq.com/cn/articles/function-switch-realize-better-continuous-implementations 接下来我们聊一聊发布.因为我们希望发布也是快速并安全可靠的. 发布是一件麻烦事.一次发布可能会需要部署多个应用,每个应用都要部署多台机器,有时候除了改代码之外,还需要修改配置,比如nginx配置等.大多运维团队都会有一些脚本来做这些变更.但这些脚本通常都藏在某些只有运维团队才知道(并有权限)的机器上,开发和业务团队都已经就绪之后,还需要等待运维团队抽出时间来做些变更,这就无形中增加的时间成本.还是在前面提到的那个项目中,作部署就是有专门的运维团队,排期来对该应用进行部署.通常又会再多等一两天. DevOps是一种团队合作的模式,即开发人员自己可以按需进行部署,不需要等待一个专门的发布团队的时间.DevOps其实现在还是没有一个标准的翻译,我的一个前同事将它翻译为“开发自运维”,我觉得还是挺贴切的. 在这种模式下,原先的运维团队应该转换自己的职责,从负责具体业务的变更,变成基础资源的提供者.比如当开发团队需要一台虚拟机,或者一个Docker集群时,能够通过简单的调用API,在很快的时间得到它,而不需要繁杂冗长的审批流程.运维团队还可以提供有效的监控、告警工具等,同样把他们以基础服务的形式提供给开发团队.就像现在AWS和阿里云做的事情. 其实很多小团队,包括我自己所在的团队,都采用了DevOps的合作模式.但是做归做,如何能做好呢?如何能够保证每个开发(甚至是入职不久的开发)能够安全快速的完成一次发布呢? (编辑:ASP站长网) |