阿里技术专家：持续交付与微服务背后的实践逻辑

第二个问题就是：“别人的功能还没做完”.假设现在团队正在进行单分支开发(也就是说所有的功能都提交在一个分支上,不会为了一个功能单独 开出一个长期存在分支).就拿图中红色线这个时间点来讲,第三个需求完成了,业务人员也认为可以做一次发布.但是同时还有另外三个需求正在开发.如果做发布的话,就会把做了一半的东西也给发上去.这是不可以接受的.

解决这个问题有两个思路：那就是功能分支和功能开关.

先看看功能分支：

每开一个新功能,就开一个分支.这个分支存活的时间通常是“周”这个数量级的.哪个功能开发完成了就合入到主干,进行一次发布.这样,其它未完成的功能还没有合入到主干,就不会造成影响.但功能分支有很多的问题,最严重的一个问题是：它和持续集成的理念是冲突的.持续集成是希望你每次提交都能够放在一起进行验证.但使用了分支的话,就只能在合并的时刻,才能真正把所有的东西放在一起进行验证.而这时发现的问题可能一周前已经发生了.

另一个方法,功能开关,会给任何一个新开发的功能在代码级别加上一个开关,使得可以简单的修改一个配置就把一个功能完全隐藏掉.默认所有的开关都是关闭的,如果一个功能做完了,想上,则修改配置,打开开关,进行一次发布即可.听起来很理想,但事实上也需要花费不少的代码来把这件事情真正做好.

关于功能分支和功能开关今天不展开细讲了.有兴趣的朋友可以参看我之前写的一篇文章：http://www.infoq.com/cn/articles/function-switch-realize-better-continuous-implementations

接下来我们聊一聊发布.因为我们希望发布也是快速并安全可靠的.

发布是一件麻烦事.一次发布可能会需要部署多个应用,每个应用都要部署多台机器,有时候除了改代码之外,还需要修改配置,比如nginx配置等.大多运维团队都会有一些脚本来做这些变更.但这些脚本通常都藏在某些只有运维团队才知道(并有权限)的机器上,开发和业务团队都已经就绪之后,还需要等待运维团队抽出时间来做些变更,这就无形中增加的时间成本.还是在前面提到的那个项目中,作部署就是有专门的运维团队,排期来对该应用进行部署.通常又会再多等一两天.

DevOps是一种团队合作的模式,即开发人员自己可以按需进行部署,不需要等待一个专门的发布团队的时间.DevOps其实现在还是没有一个标准的翻译,我的一个前同事将它翻译为“开发自运维”,我觉得还是挺贴切的.

在这种模式下,原先的运维团队应该转换自己的职责,从负责具体业务的变更,变成基础资源的提供者.比如当开发团队需要一台虚拟机,或者一个Docker集群时,能够通过简单的调用API,在很快的时间得到它,而不需要繁杂冗长的审批流程.运维团队还可以提供有效的监控、告警工具等,同样把他们以基础服务的形式提供给开发团队.就像现在AWS和阿里云做的事情.

其实很多小团队,包括我自己所在的团队,都采用了DevOps的合作模式.但是做归做,如何能做好呢?如何能够保证每个开发(甚至是入职不久的开发)能够安全快速的完成一次发布呢?

（编辑：厦门网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!