在如今的计算机行业，发布经理的工作任重而道远。一方面他们必须紧跟日益攀升的行业标准，发布速度的极限不断突破，现在要求的速度在过去是远远无法想象的。另一方面，质量的门槛也在不断抬高。
我并非诟病软件更新换代过于迅速频繁——相反，其优势是巨大的。毋庸置疑，产品发布的速度至上已成为一种行业标准，任何企业都不得不遵守。但实现高速发布的过程，却是困难重重。
这就是为什么发布经理对于一个高质量软件的高速发布至关重要。发布经理就像是整个发布进程的指挥家，必须从上到下、事无巨细地了解整个流程。但无论构建过程是属于上层还是下层，许多重大的发布管理问题都是源自于此。
在这里，我将聚焦亟需关注的三大构建发布难点。针对每一个难点，我将以描述难点、寻找原因、讨论最佳解决方案的形式展开。
难点1：保证构建质量
在加速构建的连环压力下，发布经理如何保证、保持甚至提升构建质量？越快并不意味着越好，相反，牺牲质量去提速构建生命周期，是得不偿失的。
平衡加速构建生命周期与保证质量的一种方式是减少人为因素的影响。近年来，CI/CD 和 DevOps的广泛使用，让构建自动化的CI/CD 管道会提升构建质量的观念也普及起来。“持续代码质量”之类的流行词逐渐时兴，让人满怀期待。
诚然，持续代码质量的方法对于目前的CI 进程来说还太为先进，但不可否认，CI/CD 管道一旦构建正确，将为代码质量迎来新的飞跃。此外，CI/CD 管道也可以缩短反馈循环，帮助更快找到问题根源，同时减少人为错误（主要借助自动化工具的质量控制），提升源代码的质量。
作为一个发布经理，检测CI进程是否可以顺利实现，是保证质量的重要步骤。尽管已是老生常谈，谨慎实现CI进程还是应该受到更多的关注。
自动化的进程可能损害构建质量，以越来越快的速度交付缺陷软件。有时，构建质量的恶化源于团队成员不了解整个进程，因此产生一些冲突和对抗。自动化构建产生故障的现象是常见的，例如从高度手动转向全面自动进程时，错误容易出现。但问题是没有人采取有效的自动化检测去修复这些缺陷，因此，漏洞就会在测试环节出现，甚至出现在最终交付的产品中。另一类常见的问题是，良好的自动化构建过程需要由一位构建工程师或是一名专职员工运营维护，但这类人员一般较为紧缺。
发布经理面临的最实际的问题，是明白构建一个自动化的CI/CD 管道不能解决所有问题。要实现最佳的发布结果，还需要一个持续、谨慎且有计划的转换过程，并努力平衡参与人员的需求与使用的工具。简而言之，合并一项CI进程时，除了我们都熟悉的代码质量管控之外，还需要注意CI进程本身的质量监控。
此外，自动化的使用范围也需要进行微妙的平衡。尤其是当需要执行一个手动发布的进程时，发布经理需仔细检查协议内容，决定是否能将之放入自动化测试进程，判断是否有益于整个进程。所以，这是一个关于自动化、成本、复杂性的权衡，各个公司应决定最佳组合。
此外，还有其他方面与CI进程无关的构建质量问题，但发布经理可利用转换过程，一并予以解决。发布经理应该明白，一旦转换过程获得公司支持，就可结合多种最佳的操作方式进一步排除其他缺陷，例如实行强制代码评审（支持行级评论）和产品发布后的质量监控。
同时，这也是聘请或提拔一位专门的构建工程师分担构建责任的好时机，但注意保证他们合理的薪酬（既然公司决心运用CI进程，获得一定的资金支持也相对容易些）。
值得注意的是，利用质量监控的量化指标或指示器找寻进程瓶颈的方式是不可取的。进程的瓶颈除了一些明显的量化指标，如构建失误或构建时间之外，还包括不太常见的，如执行频率和持续运行时长。
难点2：构建进程的安全性
人们普遍认为，软件的安全性会拖慢构建进程的速度。这个说法有其一定道理，但软件生产时的安全漏洞会导致更多额外的工作量，并造成长期且不可估量的后果。
保障构建安全的关键，是了解到大部分的构建可能存在安全隐患。首先，构建服务器硬件和软件可能会被盗用，尤其是为了保证远程访问的便利性，服务器与公共网络连接。从企业防火墙之外远程访问内部构建系统，虽然有其正当理由，但也可能成为黑客潜入的渠道。
另一个问题是，开发和构建环境的安全性一般都比生产环境低。开发构建环境的密码设置极为简单——甚至没有密码——却可以升级权限和许可级别，允许用户访问所有系统，运行任何类型的可执行文件。所以，对于黑客来说，进入非生产环境与进入生产环境其实一样。这就像是源代码和构建系统的后门。
为了实现安全构建，保证开发和测试环境与生产环境同样安全是极为重要的。开发者的权限和许可必须严加控制。与基础架构和构建有关的安全问题是容易理解，也易于解决的。最大的挑战在于对开发和IT运维团队进行安全教育、安全编码练习，创造安全的构建和部署系统，全面提升安全意识。
问题的难点在于实际操作中，确保构建安全涉及到如何平衡便捷与效率二者的关系。尽管各种方面的构建安全可以通过自动化的工具和进程去实现——如静态分析安全测试(SAST) 和动态分析安全测试（DAST）——但仅依赖于此是远远不够的。如在物理硬件和常规构建的安全问题中，人为错误是主要原因，必须严加防范。
挑战3：构建速度缓慢
随着企业对软件的日益依赖，发布时间变得越来越重要，冗长的发布周期必然会触碰企业的底线，对合作造成负面影响。在这争分夺秒的市场竞争中，速度慢者必将被淘汰。尽管如此，构建速度受到许多“隐藏的”障碍影响，发布经理稍不注意，工作进度就会滞后，他们的工作能力也会受到质疑。
可以看到，构建速度缓慢，其过程必然包含许多次提交（commits）（因为每次提交之后都必须暂停构建进程）。所以一旦构建中断（一个极为寻常的场景），发布经理必须找出问题的根源。如果构建中包含20 次提交，则需要耗费大量的时间，一一排查，找到出问题的根源。这还不仅仅是时间的浪费，更是精力的损耗，甚至还会不小心把缺陷构建推向最终产品。这些难点，与其他提到的问题，都在这篇博文中有详尽解释。
所以，除了保障构建系统的高质量生产、软件安全，发布经理还需面对构建速度的问题。
另外，高速生成构建的重压之下，发布经理也许会跳过许多测试或其他开发任务如静态代码分析。这些当然会影响构建的质量，所以又回到了第一个难点——质量问题。由此可见，要赢得这场高速构建的战役有多困难。
一些发布经理也许会试着对他们的构建系统中出现的特定问题做一些小修补。但正如之前提到的难点，任何简单的解决方案都会导致意料之外的结果。因为，构建进程或CI/CD 管道是构建的解决方案，而不仅仅是源代码。
大部分的构建都是由多个开发人员合作进行，甚至连代码都是用好几种语言写的（如JavaScript/Node, Swift, Kotlin, Python, Java, C#, 或 C++）。每种编程语言对应不同的应用程序，如Client, Microservices, APIs, 和 Servers。各个语言有其自身的环境、依赖关系和包管理系统（如npm (Node.js), PiP (Python), Nuget (.Net),等等）。另外还有云平台、容器和虚拟机等多种部署选择。这些导致了构建进程依赖于脆弱的本地工具链，具有太多变动因素。
当然，也有更多用重组代码加速构建的方式（如利用PCH，以及前置声明。点击可获取完整指南）。但这种方式过于复杂，而且生成的结果经常事与愿违。
另一种方式，是利用分布式计算技术，例如Incredibuild。构建/发布经理通过分发计算进程，优化构建能力，能够缩减高达90%的构建时间。这种技术无需任何源代码变更或其他的硬件设施。
Incredibuild的技术，能将执行的构建任务无缝分发至许多用户使用的远程内核或公有云中，构建节点或其他工作站/虚拟机因此成为一台功能类似于“超级计算机”的机器，拥有数百个内核和数十亿兆内存，充分利用本地网络/云中的闲置资源。Incredibuild的解决方案还提供了一种绝佳的可视化构建工具，以替代纯文本。其直观图形化的用户界面可以轻松追踪构建进程，发现瓶颈、依赖关系及错误，重启之前的构建。构建分析是重要的内容，希望我在之后会有机会写一个专题博文来进行说明。
制胜秘诀
发布经理责任重大，尤其是涉及到构建管理时。保证构建质量、提升构建效率，厘清构建安全如何影响产品质量、发布速度和安全性能。应对这些构建难点并不难，前提是需要深入理解整个构建进程，准确定位出错点，对症下药。
赢得竞争的往往不是拥有最多资源的人，而是拥有最新信息的人。希望这篇博文能对大家有所助益。
