如何提升软件发布管理过程？

在这里插入图片描述
大家都说，实践出真知。在成为一位首席技术官（CTO）之前，我也是做着跑腿活，我的职业生涯是从软件工程师开始的，后来开始管理开发和 QA 团队，并负责发布管理管道。我做过上百个项目，其中一些的软件发布过程尤为糟糕，有些甚至根本都没有这个程序，剩下的一些才有明确的发布管道。在这篇博客中，我想与大家分享一些可能会破坏软件发布的错误操作。别担心，我也会分享一些成功发布的经验。首先，让我们谈谈软件交付。

目前的许多应用程序大都是以网络为基础的，所以这些应用要么是云兼容的，要么是云原生的。但并非所有的应用都适合云端，因此大部分企业都采用了混合云或本地部署。

另一方面，开源组件在独立程序和 Web 开发中发挥着重要作用。自动化对许多公司来说也是必不可少的。移动平台又是另外一个重要的市场，有许多框架也支持移动开发。

总的来说，现在正是软件行业的黄金时代。但这些变化对于软件发布管理有何影响？从工具角度来说，影响是积极且巨大的：

如今市场上许多持续集成和持续交付的服务，避免了底层基础架构和配置的维护需求，而仅需维护管道步骤。
CI/CD 的开源组件有史以来地丰富。例如，如果没有软件即服务(SaaS)的解决方案，可以使用 Jenkins 进行本地部署。构建和测试工具，如 Cmake 和 Google C++测试框架，可用于 C++生态系统以及 Selenium 的 C++ API。
一般的IT 自动化解决方案如 Ansible，或代码包基础架构 Terraform，都可以灵活运用。
支持发布管理的服务本身也可以让大家从 Web 应用程序中操控整个流程。

美中不足的是，尽管有了这些瞩目的进展，但在发布过程的效率方面，几乎毫无进步。几十年来，我们一直在处理同样的问题:

缺乏沟通和管治
不能实现软件工程的最佳实践
团队松散无纪律

这些问题一直在影响软件交付过程，是这个伟大行业发展中的绊脚石。

找到进步空间

所以，我们在哪里出错了？应该如何改进？是时候对镜反思软件交付的过程，也许这里还有一些进步的空间。首先，让我们讨论一下在交付过程中需要避免的几个普遍问题。

鉴于应对方法不同，我们会先从技术问题出发，然后分别讨论管理问题。值得庆幸的是，技术问题一般可以通过 DevOps 解决，而且一般都有立竿见影的效果。然而，管理问题涉及到人员和文化，通常较难对付，需要更多的耐心去处理。

技术问题 1: 不靠谱的 CI/CD 系统

在这里插入图片描述

如果使用的 CI 是可靠的，那么团队的工作效率也较高。但如果 CI/CD 系统的运行时间达不到工作时间的99.5%（理想数据是100%），则会拖累公司/市场的经济。另外，大家肯定也不希望因为CI系统崩溃，导致发布延迟。大部分人并未意识到，故障停机造成的时间成本并不低。正如生产过程中的故障停机一样，CI/CD 的故障停机也同样不容忽视。CI/CD 应被看作另一个生产环境（CI/CD 也是一个产品），所以也需要设置服务等级目标（SLOs），定期安排维护。当然，还要进行测试。

尽量使用小的管道，同时确保服务器/节点的充分使用。如果任务在一个管道内等待执行，但却有两个服务器处于闲置状态，这种资源浪费的行为是让人羞愧的。

这些方法将帮助大家更加高效地使用底层基础架构。在我的个人经历中，有一次因为 Jenkins 的主实例发生了故障，而且就在发布当天，最后导致我们的发布不能继续。但如果我们能进行定期地维护，这类问题本该有效避免的。

技术问题 2: 构建缓慢

有句老话说得好，时间就是金钱。但直到进行构建和部署，看着项目里的六位工程师都闲坐着无所事事时，我才深刻体会到这句话的含义。我并不是怪罪他们，CI/CD 正在运行，然后“构建”的通知出现，这个过程也不需要他们做什么。诚然，我们也可以进行增量构建（CI 的主要目的）和小的本地构建。但这些更多的是缓解症状，并不能解决实际问题。尽管如此，我们仍然看到许多公司只运行夜间构建。

举个我做过的项目作为例子，我们当时处理每个 Pull Request 大概需要花费40分钟。如果在一个 Sprint 周期中平均出现了20个 Pull Requests，意味着因为 CI/CD 运行缓慢，我们将有13个小时无法工作，而这种情形每两周会出现一次。这只是一个很普通的例子，我了解到一些发布经理在一个构建中花费2个小时。因此无需多言，构建越是缓慢，团队的生产力就越低。

尽管可以运用一些技术加速构建，但这些技术大都是耗时的，而且要求调整代码，最终的进展也往往不如预期。处理这个问题最简单也最有效的方式，是采用分布式进程的解决方案，比如 Incredibuild，相信我，并不是因为在这家公司工作而进行推荐。Incredibuild 可以有效将任务分发到本地网络或公有云的不同机器中，加速任务执行。

技术问题 3: 自动化不足

项目部署大都需要手动进行，不仅手动部署容易出错，而且项目过于依赖特定的员工，耗时较长。正因为如此，设置自动化 CI/CD 管道应成为团队的工作重点。

手动部署也会影响发布过程和团队能力。自动化同时适用于接受度测试和容量测试。想象一下，如果 QA 团队需要在每个 Sprint 周期进行手动回归测试，这该多无趣。一般来说，我们应该尽可能多地使用自动化进程。在自动化的辅助下，我们一般能够每个月进行一到四次的部署，每周进行一次功能部署或故障修复，而且所有操作都能在正常的工作时间内完成。

技术问题 4: 环境差异

接下来是“依赖地狱”。也许你会问为什么我会如此乐观。依赖关系本质上是在本地机器上运作的，不是在 CI/CD 服务器上，也不是在同事的机器上。如果增加一个依赖关系，却没有更新 CI，问题也就随之而来了。这个问题被频繁讨论，也是每个发布经理的痛苦之源。依赖关系的管理是一项复杂的任务，尤其是涉及到遗留应用的问题。如果可以的话，请坚持特定的依赖版本，使用容器化的解决方案。根据我的个人经验，在每一个项目中，如果在依赖版本上稍有松懈，最终都会因为依赖关系变更而构建失败。

技术问题 5: 因测试失败导致构建失败

利用单元测试和集成测试覆盖应用程序的复杂部分，需要耗费大量的工作量。团队也通常倾向于跳过不稳定测试（Flaky Tests），因为测试结果是“随机的”，或者因为项目匆忙，时间紧迫，又或是觉得没有进行测试的先决条件。

成功构建的规则简单，但必须严格遵守：禁止部署阶段跳过任何测试；如果测试失败，则不能继续部署。尽管这会得罪一些研发人员或产品工作人员，但长远看来，他们会感激这严格的要求。更好地是，你可以通过寻找加速测试周期的方法，避免大家的短期情绪沮丧问题（了解 Incredibuild 的测试加速解决方案）。这些操作都有利于保留所有需要的测试。这一步骤旨在完全避免与测试相关的构建失败问题，同时尽量降低产品故障的可能性。

管理问题 1: 没有评测指标

对于产品，大家一定都有具体的标准，但是 CI/CD 工作流程有设置相应的评测指标吗？你对团队的交付能力了解多少？你应该反思以下的问题：

运行测试耗费多长时间？
CI 每天工作的时长是多少？
每天出现的正确/错误构建分别是多少？
如何知道 CI 系统故障？
从构建到产品需要耗费多长时间？
每一个管道步骤平均需要多长时间？
CI/CD 支持的并行构建是多少？

如果你无法回答上述问题，你可能也不太了解可以交付的变更数量。正如在生产环境中一样，在 CI/CD 中加入一些评测指标至关重要。以下列举了一些我在这些年的工作中总结的重要评测指标：

机器/基础架构容器的出错率
每天/每个开发者的正确/错误构建数量
每天最多的构建数量
管道工作时长

尽管这些评测指标看起来不太友善，但是这比直接指着未完成交付的员工大加责备好多了。而且你只是想“了解”项目的数据，以更好地做出预判。当数据变化时（有时会出现这种情况），你会立即知道 CI/CD 管道中的哪些地方出错了。

除了 CI/CD，在性能分析上，或者我们说生产力分析，我会使用 Incredibuild 企业版仪表板，整个构建与机器的使用情况、重要的评测指标都通过直观的图形化设计呈现出来，让人一目了然。这些构建指标包括构建执行的数量、平均构建时长、构建状态、各个机器的运算时间以及机器的利用率。
在这里插入图片描述

图1：Incredibuild 企业版仪表板

在这里插入图片描述

图2：Incredibuild 企业版仪表板

此外，为了避免在使用常规输出时有所遗漏，我推荐我的发布经理使用构建可视化工具，如 Incredibuild 构建监视器，帮助实时监控构建状态，追溯进程的发展。每一种颜色代表相关构建文件的状态，直观快速地定位构建问题（如检测耗时较长的任务、错误、警告、瓶颈、不需要的依赖项、漏洞等）。
在这里插入图片描述