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

1. 速度

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

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

2. 生产力

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

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

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

3. 可持续性

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

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

预算：您的预算太低了吗？

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

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

您有前瞻性思维吗？

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

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

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

缺乏优先级

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

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

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

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

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

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

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

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

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

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

在每周发生的数百次部署中，我们了解到应用 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（投资回报率）。领导团队使用这些指标来了解可能的改进领域并规划预算。

踏上您的旅程