Close

持续交付:业务价值、好处、挑战和指标

持续交付提高了开发团队的速度、生产效率和可持续性。

Juni Mukherjee 头像
Juni Mukherjee

特约作家

为什么选择持续交付?


听到“发布”这个词您会有什么感觉?轻松?兴高采烈?一种激动人心的成就感?终于向客户推出新功能并修复错误时,每个人都会很高兴,对吧?好吧,许多组织的不为人说的秘密是,发布版本需要花费大量的精力。如果您的团队仍然生活在为发布做准备的手动测试和手动或半脚本部署来执行发布,您的感觉可能更接近于“恐惧”和“盲目的愤怒”。

手动交付的情感周期屏幕截图

这就是为什么软件开发通过敏捷DevOps 等方法走向连续性的原因。在持续模式下,向客户频繁且可预测地发布优质产品。因此,发布相关的程序和风险降低了。如果您每天都依赖管道,您会注意到它的缺陷比每隔几周或几个月出现一次的缺陷要快得多(并解决问题!)。也就是说,通过增加产品发布频率来降低难度。持续改进的文化是衡量高绩效团队的 DevOps 指标

持续交付的重视,包括持续集成、持续测试、持续监控和管道分析,都指向了软件行业的总体趋势——帮助团队应对市场变化。毫无疑问,CD 不是“独角兽”公司和科技宠儿的专有领域。每个团队——从最卑微的初创公司到最愚蠢的企业——都可以而且应该实践持续交付。

本文探讨了进行这种切换的商业案例。它将讨论未来的工作以及使用 CD 管道交付软件将带来的好处。

查看解决方案

使用 Open DevOps 构建和操作软件

相关资料

测量部署频率

持续交付的主要业务优势


持续交付提高了软件开发团队的速度、生产效率和可持续性。

1. 速度

自动化的软件交付管道可帮助组织更好地应对市场变化。对速度的需求对于缩短新功能的上架时间至关重要。在 Time2Market(上市时间)较短的情况下,组织更有机会超越竞争对手并继续开展业务。

请记住,速度本身并不是衡量成功的标准。没有质量,速度就毫无用处。让持续交付管道将错误的代码快速发送到生产环境中没有任何价值。

缺陷

因此,在持续交付的世界中,速度意味着负责任的速度,而不是自杀式速度。

2. 生产力

生产效率转化为快乐,而快乐的团队更具参与度。

当繁琐而重复的任务(例如为发现的每个缺陷填写缺陷报告)可以由管道而不是人工执行时,生产效率就会提高。这使团队可以专注于愿景,而管道则负责执行。谁不想把繁重的工作委托给工具?

团队调查管道报告的问题,一旦提交修复程序,管道就会再次运行,以验证问题是否已修复,以及是否无意中引入了新问题。

Meeples 正在看一个软件开发工作流

3. 可持续性

企业的目标是赢得马拉松比赛,而不仅仅是短跑。我们知道在竞争中脱颖而出需要勇气,持续保持领先地位可能更加困难,这需要纪律和严谨性。全天候努力工作会导致过早精疲力尽,相反,要聪明地工作,将重复的工作委托给机器,顺便说一句,机器不需要喝咖啡也不会反驳!

每个组织,无论是不是科技公司,都在使用技术来实现差异化。由于人员比工具更昂贵,自动化管道减少了人工劳动并最终节省了成本。巨额的前期投资可能会引起缺乏经验的领导层的担忧,但是,精心设计的管道使组织能够更好、更快地进行创新以满足客户的需求。CD 在提供功能和修复方面为企业提供了更大的灵活性。特定的功能集可以发布给特定客户,也可以发布给一部分客户,以确保它们按设计运行和扩展。功能可以测试和开发,但在产品中处于休眠状态,需要多次发布。您的营销部门想在每年的行业大会上“大放异彩”?通过持续交付,这不仅可能,而且相当轻松。

持续交付的主要挑战


虽然我们坚信持续交付是正确的做法,但对于组织来说,设计和建立弹性持续交付管道可能具有挑战性。由于 CD 需要对技术流程、运维文化和组织思维进行大规模改革,因此通常感觉入门很难。它需要对公司多年来可能一直忽视的软件交付基础架构进行巨额投资,这个事实可能导致它成为一项艰难的挑战。

组织面临许多问题,以下三个是最常见的陷阱——预算、人员和优先级。

预算:您的预算太低了吗?

建设持续交付管道需要最优秀的人才,这不是一个可以掩盖成本的附带项目。我一直感到惊讶的是,一些组织一开始是分配初级成员,并在购买现代工具时偷工减料。在某个时候,他们会纠正方向,指派高级架构师投资架构解耦和弹性持续交付管道。

不要虚报低价,根据您的愿景,预留适当数量的资金,以确保执行不间断。提供持续交付管道 MVP(最低可行产品),然后将其扩展到整个组织。

您有前瞻性思维吗?

即使您有预算,归根结底,执行也可能是人员问题。

团队应该无所畏惧地自动脱离工作,转向新项目。如果有人担心自动化代理会执行他们原本要手动完成的任务,那么这些人并不适合自动化。

如果您感到停滞不前,不妨换个方式。当您的团队只要求一匹更快的马时,您需要知道如何给他们一辆汽车!在资深倡导者的帮助下快速入门,他们将引导您度过最初的难关。毕竟,员工是您最大的资产,您可以培训他们做正确的事。让做正确的事情变得容易,做错误的事情变得困难,结果会让您大为惊喜。

缺乏优先级

从来没有产品负责人说过:“我们来停止编码,建立持续交付管道!”

在防守中,他们专注于通过让世界惊艳的新功能在竞争中处于领先地位。同时,如果在每个冲刺规划器中,将管道与产品功能进行权衡取舍,您就会知道自己遇到了问题。

在一些产品待办事项中,管道(如果有的话)只能在最底层浪费宝贵的时间。短视的领导层将与管道相关的工作归类为支出,而非使团队处于良好状态的投资。他们仍然否认自己造成的长期损害,不幸的是,他们有时并不会受到损害。

管道很干净,如果您想继续业务,问问自己“干净重要吗?”。当然重要!

持续交付指标


OLTP(在线事务处理)和 OLAP(在线分析处理)是业内两种知名技术。这两个概念都适用于持续交付管道,有助于生成洞察力,引导组织朝着正确的方向前进。我们来看看怎么做。

管道会出现海量的事务数据

想象一下软件开发团队生活中的典型一天。该团队提交一项按业务优先顺序排列的功能,提交该功能的测试,并将部署与持续交付管道集成,因此每项变更都会自动部署。该团队意识到添加此新功能后应用变得缓慢,因此提交了针对性能问题的修复程序。该团队还增加了性能测试,以确保在将应用从测试升级到暂存之前,能够捕捉到错误的响应时间。

把每一次提交都看作是一项事务。软件开发团队就是这样进行的,一项又一项的事务,直到推出一款令人惊艳的产品。然后再循环往复。将这些事务乘以组织中所有工程师和团队,就可以使用大量的事务数据。

两个同事坐在带显示器的办公桌前互相看着对方的插图

这是进入下一节关于管道分析以及如何充分利用交易数据的良好切入点。

我们来分析管道的事务数据

我们能否分析事务数据以提取大量信息?当然可以!

与所有事务数据一样,庞大的数量使我们无法发挥任何意义。这就是为什么我们应该汇总和进行分析以收集对我们组织的见解。分析可以帮助我们以点见面,以下是我们如何通过管道分析和见解改善实践的三个示例。

在每周发生的数百次部署中,我们了解到应用 A 的部署失败次数是应用 B 部署失败次数的三倍。这一发现促使我们研究了应用 A 在环境稳定性和配置管理方面的设计选择。我们了解到,该团队在其数据中心使用不稳定的虚拟机进行部署,而应用 B 则采用容器化方式。我们优先考虑对不可变基础架构的投资,并在一个月后进行了检查,以确保该投资的回报良好。果然,确实如此。可以测量,也可以修复。

另一个例子是,当我们得知应用 B 的静态代码分析错误在过去几个季度中稳步上升时,这可能意味着应用 B 背后的团队需要(重新)培训才能编写更好的代码。我们还发现,静态代码分析器出现了误报,这意味着它们在没有出现编码违规情况时就标记了编码违规。因此,我们将他们的分析器升级为知名行业标准工具,并在一定程度上减少了误报。我们组织了一次编码研讨会,讨论并解决了合理的静态分析错误。最后,团队又重现欢声笑语。

另一个有趣的见解是,应用 A 的单元测试的代码覆盖率低于应用 B 和 C,但应用 A 的生产问题数量是去年最少的。编写单元测试和测量代码覆盖率都很好。过度练习对团队没有成效,对客户也毫无用处。吸取的经验教训。

关键绩效指标 (KPI)

在引导组织朝着正确的方向前进时,我们不能依赖意见。首先,我们需要根据成功的样子来定义 KPI。其次,我们需要通过分析月、季度和年份的 KPI 来做出以数据为导向的决策。

组织 KPI 与部门 KPI

很多时候,我们已经看到各个部门定义自己的成功指标。只要这些指标与组织的目标相关,了解成功对各部门来说都是一件好事。

测试失败、暂存失败与生产失败

一些组织要求开发人员负责测试环境,QA 负责暂存环境,运维人员负责生产环境。与其让开发人员被测试环境中运行的单元测试的代码覆盖率报告所困扰,不如让他们退后一步,着眼于全局,无论他们是否负责环境,这点非常重要。

性能测试导致的暂存失败百分比可能很高,这可能是由于性能基准测试不正确或代码缓慢所致。比较分析可能表明,管道在生产中的集成冒烟测试中失败率最高,因此值得进行调查。根本原因可能是产品中的真实错误,也可能是错误的测试代码、不准确的测试数据、错误的测试配置、产品和工程之间的误解等。

进一步挖掘可能会发现错误的测试配置猖獗,您可以优先修复这些问题以修复频繁的集成故障。此外,开发人员自始至终拥有自己的代码也符合 DevOps 范例。

稳定性指数

一旦我们定义了 KPI,就必须了解单个 KPI 是否存在偏差以及在任何特定方向上严重偏差。如果是这样,我们需要将其与其他使重心接近中间的 KPI 保持平衡。其中一个 KPI 就是稳定性。

开发人员使用 FeatureLeadTime(功能提前期)来衡量稳定性,这是一项功能在生产中上线所花费的时间。一项功能包含多个提交,因此对 FeatureLeadTime 更精细的衡量标准是CheckIn2GoLive,即签入到在生产中上线所需的时间。

通过管道测量 CheckIn2GoLive,因为这可以用管道将代码从测试提升到暂存再到生产所需的时间来估算。此外,CheckIn2GoLive 还反映了 MTTR(平均解决时间)缺陷,因为错误修复在从测试到暂存再到生产的整个流程中都要经过相同的流程。

有趣的是,当我问运维时,速度通常具有负面含义,因为他们习惯规避风险。他们衡量逃脱的缺陷数量以反映故障,并根据管道发现的缺陷与逃脱的缺陷的百分比来定义稳定性。

业务根据客户满意度或回头客数量来定义稳定性。虽然这听起来很主观,但您可以通过客户提出的缺陷数量或客户反馈调查来估算该指标。

稳定性指数就是一个典型的例子,其中开发人员、运维和业务部门从自己的角度出发,坚持己见,但是,组织最好创建混合指数,而不是依赖单独一个部门的意见。因此,需要创建一个公正的组织稳定指数。性

代码质量指数

另一个需要考虑不同观点的示例是代码质量。有人说我们代码的质量反映在通过单元测试衡量的代码覆盖率上,而另一些人则说这是循环复杂性。标准静态分析器会报告代码重复、安全漏洞和潜在的内存泄漏。所有这些都是衡量代码质量的真正指标,因此创建了一个索引,其中所有这些,可能还有其他因素,都在其中发挥作用。

业务KPI 与技术 KPI

组织喜欢关注的另一个热门 KPI 是冲刺所带来的价值。一种常见的不良实践是记录版本数量,这本身并不能增加价值。您可以将位从 A 点移到 B 点,而不必为业务提供动力,但这还不够好。一些组织衡量的是该冲刺中新添加的测试数量或执行的测试总数,这些也不反映业务结果,仅反映工程工作量。冲刺中提供的价值必须与业务相关。

业务 KPI 的例子可能包括上个季度的客户获取数量和上个月的广告点击量,管道不会直接影响这些业务指标。我们尝试将业务 KPI 映射到技术 KPI 的唯一原因是要了解技术工艺与业务目标的关系。

将业务 KPI 映射到管道还可以帮助我们计算管道的 RoI(投资回报率)。领导团队使用这些指标来了解可能的改进领域并规划预算。

踏上您的旅程


不要浪费时间争论持续交付是否适合您,持续集成是否足够,或者持续部署是否是您的极乐世界。如果您踏上这段旅程,它将为您的团队不断进步创造机会!这将帮助您的团队放心地进行实验,让他们不会因为“午夜”发布而精疲力尽。

通过我们的 DevOps CI/CD 教程了解如何构建持续集成、交付和部署 (CI/CD) 管道。此外,Atlassian 的 Open DevOps 还提供了一个开放的工具链平台,允许您使用自己喜欢的工具构建基于 CD 的开发管道。

Juni Mukherjee
Juni Mukherjee

Juni is a thought citizen in the DevSecOps space and has made deep investments in the field of Continuous Delivery. She has helped organizations build Continuous Delivery Pipelines, and would love to solve the problems that plague our industry today. She has authored a couple of books.


分享这篇文章
下一个主题

推荐阅读

将这些资源加入书签,以了解 DevOps 团队的类型,或获取 Atlassian 关于 DevOps 的持续更新。

Devops 示意图

DevOps 社区

Devops 示意图

阅读博客文章

地图插图

免费试用

注册以获取我们的 DevOps 新闻资讯

Thank you for signing up

后续内容
价值流映射