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

Dori Exterman
Dori Exterman / 2月 13 2020
如何提升软件发布管理过程?

来自一位研发副总裁的建议,他同时也负责发布管理管道。

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

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

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

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

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

 

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

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

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

进步空间…

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

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

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

CI/CD

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

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

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

Accelerate your CI_CD pipeline by up to 30X. Learn more

技术问题 #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 企业版仪表板,整个构建与机器的使用情况、重要的评测指标都通过直观的图形化设计呈现出来,让人一目了然。这些构建指标包括构建执行的数量、平均构建时长、构建状态、各个机器的运算时间以及机器的利用率。

IncrediBuild’s Enterprise dashboard图1:IncrediBuild 企业版仪表板
IncrediBuild’s Enterprise dashboard图2:IncrediBuild 企业版仪表板

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

Build Monitor

图3:IncrediBuild 构建监视器

构建监视器还可以控制CPU的使用情况、待执行的任务、内存使用、I/O等等。

管理问题 #2: 缺乏管治

除了精准地使用完善的指标和最佳的工具之外,清晰的规则和交付流程也同样重要。成功是无法保证的,但却可以无限接近。如果一个项目缺少完善的发布管理,那还不如一个有CI/CD系统故障的项目。

管治主要是沟通和责任,沟通意味着各种文件说明。在功能发布时,确定一个联系人,并明确某项内容发布时的具体通知对象,这些细节都是极其重要的。事实上,根据个人经验,一个项目至少应该有下面这些文件:

  • 一个正式的发布计划,包括发布检查清单、回滚机制和风险缓解计划等内容;
  • CI/CD基础架构说明,如何部署代码(管道的详细说明);
  • 共享发布日历;
  • 有效的沟通途径,保证及时通知参与项目的工作人员,准确告知新功能部署时间。

我记得我曾参与过一个大的电讯公司的项目,项目是夜间进行部署(从午夜到凌晨六点)。工作要求大家轮流进行部署。一天晚上,其中一个团队忘记报告他们的进程,但其他团队又不知道该向谁确认。因为这个差错,所有的团队都无法继续部署。如果能集中地说明谁负责每个团队的部署,这个问题本该可以轻易避免。

写在最后

软件发布管理主要被认为是软件行业的一门重要学科。虽然每个项目都不太一样,代码发布到产品的过程也因项目、公司的差异而变化,但也不乏一些优秀的实践操作,行业参与者(甚至是领导者)都应该遵循。

在本篇博客中,我分享了一些我在该领域多年工作经验中总结的最佳实践。虽然在理论上都同样重要,但在实际操作时,可以根据轻重缓急进行优先选择。另外,对于任何项目来说,在团队中实现“质量第一”的文化,并努力执行才是重中之重。

订阅博客

阅读 Incredibuild 独家内容

Dori Exterman

Dori Exterman 是一名软件开发专家、产品策略分析师,在软件开发行业拥有 20 年的工作经历。作为 Incredibuild 的首席技术官(CTO),他指导公司的产品策略,负责规划产品前景、执行方案、选择技术合作伙伴。在加入 Incredibuild 之前,Dori 在软件公司身兼数职,主要负责各种技术和产品开发,聚焦系统架构、产品性能、先端技术、DevOps、发布管理和 C++.他是开发工具先进技术领域的专家和分享者。