请选择 进入手机版 | 继续访问电脑版

ITIL,DevOps,ITSS,ITSM,IT运维管理-ITIL先锋论坛

 找回密码
 立即注册

扫描二维码登录本站

QQ登录

只需一步,快速开始

查看: 284|回复: 0

持续交付到底有什么价值?

[复制链接]
匿名  发表于 2021-12-20 20:28:30 |阅读模式
“持续交付”定义为“一套软件工程方法论和许许多多的最佳实践的集合”。
持续集成、持续交付和持续部署的关系
通常会把软件研发工作拆解,拆分成不同模块或不同团队后进行编码,编码完成后,进行集成构建和测试。这个从编码到构建再到测试的反复持续过程,就叫作“持续集成”。

在“持续集成”之后,获取外部对软件的反馈再通过“持续集成”进行优化的过程就叫作“持续交付”,它是“持续集成”的自然延续。
“持续部署”又是什么呢?软件的发布和部署通常是最艰难的一个步骤。
“持续部署”就是将可交付产品,快速且安全地交付用户使用的一套方法和系统,它是“持续交付”的最后“一公里”。
“持续交付”是一个承上启下的过程,它使“持续集成”有了实际业务价值,形成了闭环,而又为将来达到“持续部署”的高级目标做好了铺垫。
从“持续部署”(自动化发布)开始推进“持续交付”,这才是一条优选的路径。

持续交付的显性价值
持续交付也通常以“发布流水线”的方式来解释,即研发团队从开发,到测试,再到部署,最终将产品交付给最终用户使用的过程。
粘贴上传202112202027335858..png

通过持续交付新的软件版本,以验证新想法和软件改动的正确性,并衡量这些改动对软件价值的影响。这里说的“软件价值”,说白了就是收入、日活、GMV 等 KPI 指标了。
通常我们在实施持续交付后,都能够做到在保证交付质量的前提下,加快交付速度,从而更快地得到市场反馈,引领产品的方向,最终达到扩大收益的目的。
持续交付的能力,正成为评定一家互联网公司研发能力的重要指标。

如果你是 CTO 或者是一个较大规模研发团队的管理者
你是不是时常困扰于技术选型的问题?
技术选型最大的难点在于影响大,又难以验证(或者验证效率低下)。而造成这些困境的绝大多数原因是没有合适的测试环境,比如环境差异造成测试数据缺乏说服力,又比如缺少隔离环境造成服务冲突等等。而这正是持续交付的用武之地。持续交付的实施,将全面改善企业对测试环境的管理方法,使得环境管理更合理、更自由。
你是不是经常头痛于已制定的标准难以落地?
标准、规范、流程的落地,都需要载体,而最好的载体就是平台工具。而持续交付是一整套平台工具的落地,几乎涵盖了研发的整个生命周期,是天然的、最佳的载体。另外,持续交付的落地本身就伴随着各类标准、规范、流程的制定和实施,可以说两者相互依存,是非常好的管理思想落地方案。
你是不是时常考虑如何提高跨部门协作的效率?
我看到的每一个持续交付实施团队,都可以说是最厉害的“拆墙大队”,拆的就是各个研发协作部门间的“隔离墙”。持续交付能够向各个协作部门输出统一的标准、流程和工具,提升沟通效率;并且通过大量的自动化,进一步提升各部门工作效率;还可以快速集成,把各个分散的团队,无论是横向的业务研发团队,还是纵向的技术框架团队,紧紧地联系在一起,共同进退。
你是不是担心“黑天鹅”的降临?
既然叫“黑天鹅”,那就是说明它的产生有一定的必然性。正应了一句老话“是福不是祸,是祸躲不过”,既然躲不过,那就解决它呗。其实任何故障都有一个天敌,叫作:快速恢复。假设,所有的故障都可以在 3 分钟内恢复,你是不是觉得天下无敌了。那恢复故障最快、最有效的手段又是什么呢?当然就是回滚(或重新部署)了,而这正是持续交付所包含和着力打造的能力之一。

如果你是 Team Leader
你一定希望团队的知识能够传承。
互联网公司的人才流动之频繁已经远远超过了你我的想象。人来人往,如何将知识传承下来呢?其实在这方面,持续交付也能为团队提供很多帮助。首先,持续交付将团队赖以生存的工作流程进行了固化;其次,利用代码静态检查等工具,能够很好地传承团队多年来的代码规范,并作为检查项进行自动化校验;再次,自动化测试的脚本,同样是团队经验的产物。
你一定希望团队专注于业务而非工程。
目前越来越多的公司或研发组织意识到,持续交付体系也如同中间件一样,能够从日常的业务研发工作中抽象出来,其不同只在于中间件解决架构问题,而持续交付解决工程问题。这样研发团队能够全力应付业务的需求,而不用总是重复奔波于一些烦人且耗时的工程问题,比如安装测试机、准备编译服务器等等。
你一定希望以一个较平稳的节奏持续工作。
虽然在实施持续交付的初期,团队为了适应新的流程和工具,会有一定的效率下降,但之后在自动化的帮助下,团队效率会有一个明显的提升并逐渐稳定下来。持续交付就是这样通过稳固的流程、自动化的工具和公开而真实的数据,来避免发布前夕容易发生的“死亡行军”式开发阶段。

如果你是产品经理
你应该是产品真正的第一个用户。
持续交付不仅仅是可以保证每一个变化都能及时得到测试以及反馈,更多的是解决测试与实际发布时存在差异的问题。产品人员再也不会陷入“为什么用户端运行的结果,和在测试环境中的不一致”这样的窘境,他们将真正成为第一个用户,而不再是最后一个 QA。
你应该完全知悉当前的进度和质量。
作为产品人员,你是不是一直有这样的感觉:和研发团队之间总有一扇墙,程序员们似乎并不乐意告诉产品人员项目的真相;而最终总有这样那样的理由造成延期,产品人员往往无话可说。那么,持续交付就能够实时地反应当前的开发情况,从而帮助产品人员决策和调整。
你的产品应该随时能发布。
计划永远赶不上变化,任何产品人员都希望自己的产品能够随时处于可发布状态。这样就能灵活地交付已完成的功能,迎合市场或业务的需要。本质上,做到代码上线和业务上线的解耦分离,这也正是持续交付方法论强调的一个重点。

如果你是一个程序员。
你可以通过对持续交付的学习,进一步加强自己对整个软件工程的认识。
持续交付涵盖了软件交付端到端的整个周期,其覆盖面不仅仅包括编码,还包括:设计、测试、部署、运维、运营等等。如果你对自己的发展有更高的要求,那么你就应该学习一下持续交付的内容,它能让你看到更多与编码有关的其他东西,比如不同的编码方式等;也能让你站在更高的角度去看待自己的工作:研发效率的提高往往不是个人能力的提高,而是集体协同效率的提高。
你可以利用持续交付的工具或最佳实践,提高自己的工作效率和质量。
随着持续交付的流行,其配套的实践和工具也层出不穷。如果你玩过 ping-pong 式的结对编程(A 写测试,B 写实现,然后 B 写下一个测试,A 写重构和实现),你一定会觉得编程如此轻松有趣,而这种 TDD 的方式也很好的保证了代码质量。
你可以参与到持续交付实施中去,享受为其他程序员提供效率工具的挑战和乐趣。
试想一下,如果你是一个出租车司机,而你的乘客却是舒马赫(F1 世界冠军),此时你开车的压力会有多大。其实参与到持续交付的实施中也是一样,因为你正在用程序员的方式改造程序员的工作习惯,为程序员提供工具。虽然挑战和压力巨大,但这又是如此有趣,你将会站在另一个高度去看你曾经的工作。(转自Lomo)







上一篇:华为质量流程IT总裁陶景文:任何不涉及流程重构的数字化转型,都是在装样子 | IDCF
下一篇:DevOps 到底是什么?5分钟了解
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

参加 ITIL 4 基础和专家认证、长河ITIL实战沙盘、DevOps基础级认证、ITSS服务经理认证报名
ITIL(R) is a registered trademark of AXELOS Limited, used under permission of AXELOS Limited. The Swirl logo is a trademark of AXELOS Limited, used under permission of AXELOS Limited. All rights reserved.

QQ|ITIL ( 粤ICP备11099876号 )|appname

GMT+8, 2022-12-7 17:15 , Processed in 0.096230 second(s), 30 queries .

Powered by Discuz! X3.4 Licensed

Copyright © 2001-2020, Tencent Cloud.

快速回复 返回顶部 返回列表