来自一位研发副总裁的建议，他同时也负责发布管理管道。
大家都说，实践出真知。在成为一位首席技术官（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:自动化不足
都已经2020年了，但是项目部署却大都需要手动进行。手动部署容易出错，且项目过于依赖特定的员工，耗时较长。正因为如此，设置自动化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 构建监视器 ，帮助实时监控构建状态，追溯进程的发展。每一种颜色代表相关构建文件的状态，直观快速地定位构建问题（如检测耗时较长的任务、错误、警告、瓶颈、不需要的依赖项、漏洞等）。
图3：IncrediBuild 构建监视器
构建监视器还可以控制CPU的使用情况、待执行的任务、内存使用、I/O等等。
管理问题 #2: 缺乏管治
除了精准地使用完善的指标和最佳的工具之外，清晰的规则和交付流程也同样重要。成功是无法保证的，但却可以无限接近。如果一个项目缺少完善的发布管理，那还不如一个有CI/CD系统故障的项目。
管治主要是沟通和责任，沟通意味着各种文件说明。在功能发布时，确定一个联系人，并明确某项内容发布时的具体通知对象，这些细节都是极其重要的。事实上，根据个人经验，一个项目至少应该有下面这些文件:
- 一个正式的发布计划，包括发布检查清单、回滚机制和风险缓解计划等内容；
- CI/CD基础架构说明，如何部署代码（管道的详细说明）；
- 共享发布日历；
- 有效的沟通途径，保证及时通知参与项目的工作人员，准确告知新功能部署时间。
我记得我曾参与过一个大的电讯公司的项目，项目是夜间进行部署（从午夜到凌晨六点）。工作要求大家轮流进行部署。一天晚上，其中一个团队忘记报告他们的进程，但其他团队又不知道该向谁确认。因为这个差错，所有的团队都无法继续部署。如果能集中地说明谁负责每个团队的部署，这个问题本该可以轻易避免。
写在最后
软件发布管理主要被认为是软件行业的一门重要学科。虽然每个项目都不太一样，代码发布到产品的过程也因项目、公司的差异而变化，但也不乏一些优秀的实践操作，行业参与者(甚至是领导者)都应该遵循。
在本篇博客中，我分享了一些我在该领域多年工作经验中总结的最佳实践。虽然在理论上都同样重要，但在实际操作时，可以根据轻重缓急进行优先选择。另外，对于任何项目来说，在团队中实现“质量第一”的文化，并努力执行才是重中之重。
