软件高效交付10大策略解读——小批量持续流动博文视点Broadview关注共 2323字,需浏览 5分钟 ·2022-05-09 20:00 软件交付过程是指在编程序改代码之后的一系列活动,如提交、集成、构建、部署、测试等,直到将软件发布给用户使用。我们大致梳理了软件开发 “从古至今”的思潮、运动、方法、实践,从软件工程到 DevOps,再到研发效能,它们之间有演进、有纠偏、有补充,也有大量的交叠。做这样的梳理,是为了能够融会贯通,以便综合运用。本系列文章就来看看对它们做到融会贯通以后,提炼出来的软件高效交付的10大策略。本文先来解读其中的第一个策略:小批量持续流动。软件交付过程要追求快,从改一行代码到把它发布上线,都要尽量快。因为从确定需求到设计开发再到发布上线的整个流程,就是要尽量快。那么如何做到呢?一个重要的策略就是不要等待,小批量持续流动。大批量带来的等待问题观察瀑布模式中的等待:由于大批需求被一起规划设计,所以尽管每个需求可能只需要不多的设计时间,但是需要等待所有的需求都被设计好后才能开始实现。大批需求带来很大的开发工作量,在实现某一个具体小功能时,可能只需要不多的时间,但需要等待所有的功能都实现后,才能进行集成。大量的软件改动带来繁重的集成工作,如果到项目后期才集成和测试,那么就要等问题一个个冒出来并被解决掉,说不定还需要多轮测试。总之,对于软件的一点改动,花在它本身的功能设计、代码实现、质量保证上的时间可能并不多,但是由于总是需要凑齐足够的需求才能往下推进流程,所以等待的时间就会很漫长。最后的效果就是从确定需求到发布上线的整个流程,很慢。具体到《软件交付通识》这本书关注的软件交付过程,也是很慢的。当总是需要凑齐需求时,还会带来一些连锁反应,让流程变得更慢。其中最明显的问题是,修复一个Bug所花费的时间变长了。比如你改了几行代码,当时就得到了反馈,提示写得有问题,那么你自然就只需要在那几行代码中排查。那几行代码又是刚写的,记忆还新鲜,很快就能找出原因并改正。但是,如果过了很久才得到反馈,那么你就不知道问题是具体哪个地方的改动引起的,从而导致排查困难。而且那段程序的结构和逻辑,你可能也记不清了,又要重新熟悉,重新进入状态。短周期、小颗粒度、减少半成品才是王道这么看来,等待真不是一件好事儿,要尽量避免。如何避免呢?别凑一大批!也就是说,要在各个方面追求小批量:小批量的设计功能、交代开发任务,小批量的集成,小批量的测试,小批量的发布。这样就有可能让整个流程持续地流动起来,而不是走走停停。瀑布模式显然违背了这一策略,导致了漫长的交付周期。而如果将四周甚至两周作为一个迭代周期的话,相比之下就好得多。然而这并不是终点,它可以更好:一方面,迭代可以一直延伸到上线,而不是止步于内部演示版本,上线才是真正的Done;另一方面,一次迭代包含了多个需求,它们之间还是会相互等待、相互影响的。所以,更理想的情况是每个需求都可以在精益看板墙上不受干扰自主地往前走:开发、测试直到发布。也就是说,想改就改、想测就测、想发就发。这里需求的颗粒度也有讲究,不要太大。所以在精益需求分析与管理实践中,要做需求拆分:将大需求拆分成小需求,可以分别独立开发和发布上线。这也符合小批量的原则。在精益方法中还提到了控制在制品数量,因为在制品数量大意味着排队等待时间长,也意味着一个人可能要并行处理多件事情,需要频繁切换。控制在制品数量,也符合持续流动这个原则。小批量持续流动的交付过程以上是从敏捷和精益的视角来看小批量持续流动这个策略的。下面我们来看看持续集成、持续交付是如何践行小批量持续流动这个策略的。持续集成意味着代码改动要及早和经常提交与合并,这样有利于减少合并冲突和错误,并且在彼此工作有依赖时,能及时获取到别人的改动,及早开工。持续集成还意味着及早和经常构建与测试。一旦收到提交的代码,就自动进行构建、静态代码分析、单元测试等工作,以便尽早发现问题,而不是非要凑齐再开始。显然,这也符合小批量持续流动的原则。持续交付更进一步,把及早和经常做的事情扩展到了部署到测试环境并测试,甚至扩展到了及早和经常发布上线。可见,敏捷、精益、持续集成、持续交付,它们都反映了这个重要的策略:小批量持续流动。以上讲的是大的方面。根据小批量持续流动这个原则,在集成发布阶段还有不少细节值得注意。比如发布窗口应当尽量去掉,做到无须等待、随时发布。推荐阅读董越老师的新书《软件交付通识》从头到尾梳理了软件交付过程(也就是从改了一行代码到它发布上线的过程),分门别类地讲解了流程各个阶段的各个要点,以及流程中各个活动的各个要点。软件高效交付的10个策略更是这本书中的核心观点和内容,如果你想快速通读所有10个策略,请关注这本不容错过的好书。作者简介:董越,DevOps 资深专家,阿里巴巴集团前研发效能事业部架构、高级产品专家等职,从事 Aone&云效 DevOps 产品设计、阿里云专有云集成与交付解决方案设计等工作。在加入阿里之前,他还曾就职于西门子、摩托罗拉、雅虎、索尼、去哪儿网等大型企业,一直从事软件配置管理、软件集成与交付、DevOps 相关的工作。当前主要从事企业级DevOps体系建设与咨询工作,帮助众多企业提升软件研发交付效能。已服务过的客户有华为、工商银行、交通银行、招商银行、中信银行、中国移动、中国联通、中国电信、华泰证券、泰康人寿等。 如果喜欢本文欢迎 在看丨留言丨分享至朋友圈 三连 热文推荐 解密支付系统,来看如何构建理想的支付系统架构手把手带你用Zabbix进行操作系统监控掌握这些Python的高级用法,让代码更可读、运行更高效!书单 | 这几本技术类新书,看完要登峰造极了!▼点击阅读原文,了解本书详情~ 浏览 5点赞 评论 收藏 分享 手机扫一扫分享分享 举报 评论图片表情视频评价全部评论推荐 持续交付2.0持续交付2.00持续交付2.0本书重新定义了“持续交付”,增补了组织管理和系统架构两个维度,并辅助以真实案例,对诸多持续交付原则与高效持续测试策略的4个要素软件测试test0持续交付 : 发布可靠软件的系统Jez Humble编著的《持续交付(发布可靠软件的系统方法)》讲述如何实现更快、更可靠、低成本的自持续交付 : 发布可靠软件的系统持续交付 : 发布可靠软件的系统0持续交付的本质春哥叨叨0一文教你分清持续集成,持续交付,持续部署!测试开发技术0Screwdriver持续交付构建系统Screwdriver是 Yahoo开源的持续交付构建系统,Screwdriver的一些关键设计功能帮助Yahoo实现了大规模持续交付能力。从宏观看,这些关键设计是:使部署管道容易优化主干开发使回滚容Screwdriver持续交付构建系统Screwdriver 是 Yahoo 开源的持续交付构建系统,Screwdriver 的一些关键设聊聊持续交付这点事儿架构师修行之路0点赞 评论 收藏 分享 手机扫一扫分享分享 举报