阿里技术专家：持续交付与微服务背后的实践逻辑
|
副标题[/!--empirenews.page--]
《阿里技术专家：持续交付与微服务背后的实践逻辑》要点： 崔力强 阿里巴巴技术专家
前言大家好,我是崔力强.目前在阿里巴巴任职.负责一款持续交付领域的SaaS产品的开发.非常高兴能够和大家分享持续交付和微服务的话题. 本次分享的重点是持续交付.也会提到一些微服务的概念,以及持续交付和微服务之间的关系.今天会涉及的一些实践可能大家或多或少有所耳闻.我会着重讲述这些实践背后的逻辑,及它们之间的关系. 先看一看提纲：
持续交付的概念关于持续交付的概念.从《持续交付》这本书的副标题可见一斑：“发布可靠软件的系统方法”.可以看到这本书中讲的“持续交付”主要是技术相关的实践,虽然近年有些朋友把持续交付的概念进行了延伸,把精益需求管理和精益创业也包含了进来,不过今天我还是会按照它最初的内涵,只讲技术相关的实践. 这里其实有两个概念,第一个是,怎么样才算持续交付,也就是目标；第二个是,如何做到持续交付,也就是一些技术实践. 为了了解“怎么样才算持续交付”,让我们先解剖一下软件开发的过程. 针对单个需求来说,我们会先进行需求分析、细化.然后开发和测试.部署时,需要拷贝一些文件到一些机器,运行一些脚本,有时候还需要改一些配置文件或者做一些数据迁移等. 然而在实际的项目中,肯定不会只有一个需求.需求会源源不断地输入到开发团队.下面是一个开发团队随着时间进行需求开发的示意图.蓝色的条是开发某个功能的开始时间和结束时间点.有的需求占用时间长,有的需求占用时间短. 在每个功能的完成时刻,对于业务方来说,都可能是一个可以发布的状态(也有可能不是,比如业务方认为相关的几个需求必须都做完了才能一起上,或者需要等到某个特定的时间点才能上).那么如果立马就能够进行一次发布,并且能够快速并且安全的完成这次发布,则能够对业务的发展具有非常积极的作用.也就是在下图的这些时刻. 这些时刻,不一定每个都需要发布.但作为开发团队,要给业务方足够的灵活度.所以持续交付的目标,并不是每次提交都进行发布,而是每次提交都是可发布的状态.这就回答了“怎么样才算持续交付”这个问题.再换一种方式来说,持续交付是对业务方友好的一种,开发团队的开发节奏. 接下来就要讨论使用什么样的技术实践来达到这种开发节奏.为了讨论具体的技术实践,首先来看看在软件开发中有什么因素会阻碍我们达到这种节奏. 持续交付会遇到的问题及解决方案第一个问题是：上线前总还是要做测试的吧,至少做一遍重要功能的回归测试(手工回归本身其实也是有章可循的,推荐我同事的一篇文章：https://yq.aliyun.com/articles/6898).随着一个系统上的功能越来越多,每次上线前需要测试的东西就越来越多.慢慢的,发布就慢下来了.我曾经工作过的一个系统,上面承载了三块业务,有将近40多个人在上面工作.每次发布前都要先进行几天的回归测试,顺利的话,从确定要发布的版本到验证完该版本,确定可以发布,也要差不多一周的时间. 另一个我工作过的项目规模要小一些,做一次发布也需要一天的时间来回归,通常都会发现一些问题.顺利的话,可以在当天把所有的问题修复掉,进行发布.不过因为bug没修完而不能当天发布,拖到第二天的这种情况也时常发生. 甚至有一次,到了晚上九点多的时候还没有修完bug,但当时大家都憋着一口气,硬是要发,结果发到了晚上一点多. 因为成本高,所以不敢做的太频繁；做的不频繁的话,就会在发布中积累更多的功能,从而进一步增加出问题的可能性,从而形成一个恶性循环. 作为一个妥协,人们不得不使用瀑布或者迭代内小瀑布的开发模式. （编辑：厦门网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
