作者：乔纳森·巴特利特（Jonathan Bartlett），美国沃尔特·布拉德利自然与人工智能中心（WALTER BRADLEY CENTER FOR NATURAL & ARTIFICIAL INTELLIGENCE）高级研究员

Jonathan Bartlett 是 Specialized Bicycle Components （美国美国公司，设计、制造和销售自行车、自行车零部件及相关产品，品牌为“Specialized”。）的高级软件研发工程师，他专注于解决跨多个软件团队的问题。此前，他是 ITX 的高级开发人员，为美国各地的公司开发应用程序。他还担任布莱斯研究所所长，专注于数学、哲学、工程和科学之间的相互作用。乔纳森是多本教科书和编辑书籍的作者，这些教科书和编辑书籍已被普林斯顿大学和德弗里大学等多所大学使用。

在规模较小的开发组织中，软件的构建流程往往被忽视。如果您不是软件开发人员，那么构建流程就是将源代码创建成最终软件包并交付给客户（或服务器）的一系列步骤。

多年来，大型企业一直在实现构建流程的自动化，原因很简单，构建流程必须适用于众多软件开发人员。它必须每次都能在每个人的机器上运行，并产生可靠的结果。 因此，将这一流程传达给每个人所需的文档量与简单地将其自动化之间的差距并不大。然而，在规模较小的组织中，人们很容易将过程自动化视为不必要的开销而绕过它。这种逻辑是这样的--如果只有 Sam 负责 X 产品，那么就只有他需要构建 X 产品。只要构建系统能让 Sam 轻松工作，这就足够了。不过，即使是对单个开发人员的组织而言，构建过程自动化也能带来许多优势。下面，我将向您介绍这种流程的组成部分，以及为什么它们对任何规模的开发组织都很重要。

虽然构建自动化构建流程有多种方法，但每个构建流程都始于版本控制的源代码。频繁提交的版本控制软件应该是每个开发组织的基石。自动构建流程只能直接从版本控制的源代码库中构建。这将迫使开发人员使用该系统，并确保所有构建的代码都已正确检查到源代码库中。我曾多次遇到过这样的情况，开发人员在发布产品时忘记提交代码，而我不得不追查这些代码。我不得不搜索已离开组织的开发人员的备份硬盘，以找到实际交付的代码。此外，当代码必须在构建之前提交时，就意味着你可以可靠地找到哪些版本的代码进入了哪些版本。错误是在 3.5.1 版和 3.5.2 版之间引入的吗？如果是在版本控制系统中构建的，那么获取这两个版本之间的所有变更列表就轻而易举了。

自动构建流程所需的下一个要素是构建流程本身。 这是实际执行构建的脚本或脚本集合。有了自动化流程，开发人员就必须明确写下构建流程所需做的所有事情。我不知道有多少次，开发人员告诉我 "构建流程很简单"，但实际上却需要执行一个或多个非标准步骤。 自动构建流程意味着开发人员必须将所有这些步骤写入脚本，这样就很容易检查了。

标准化环境

构建流程的另一个重要方面是拥有标准化的环境。两个开发人员可以拥有相同的代码，运行相同的构建步骤，但一个开发人员可以编译，另一个却不行。是开发工具的版本错误？错误的 Windows 版本？是否有某个开发人员安装了某些东西，而另一个开发人员没有？通过 Docker 等工具，您可以创建甚至拥有一个精确的构建环境配方。使用 Docker 来运行构建环境，不仅可以指定（和版本控制）构建环境所需的确切组件，还可以创建一个逐位的构建系统映像。这样，代码是如何构建的就不会含糊不清了。例如，假设 2.1.1 版本存在安全漏洞，但您正在发布 5.6.2 版本。很多时候，开发环境已经发生了很大变化，您甚至不记得 2.1.1 版需要安装哪些工具。但是，如果您使用 Docker 作为自动构建系统的一部分，那么每个版本的整个工具链都会记录在案。

最后是版本控制过程本身。开发过程中一项恼人的任务就是确保正确的版本号附在代码上。这项工作可以通过自动构建系统实现自动化。我通常会这样设置我的构建系统：用一个特定格式的标签（如 release-1-2-3）标记版本库的版本，就能完成多个重要步骤。首先，它会促使自动构建过程将版本信息设置为 1.2.3。这通常由 shell 脚本完成，脚本会修改代码中的一些常量来设置版本信息。此外，自动构建流程工具通常也有一个构建编号，也可以使用。其次，我通常会让自动构建流程将生成的代码存储在一个特殊的位置，而这个位置本身就有版本信息。例如，如果是网络应用程序，我可能会构建一个 Docker 镜像，并将其存储在一个 Docker 存储库中，该存储库也会标记版本信息。

那么，要开始进行自动化构建，你需要哪些工具呢？事实上，这些工具都是现成的。 大多数版本控制软件中都嵌入了此类工具。Github 有 "Github Actions"，Bitbucket 有 "Bitbucket Pipelines"。还有一些其他工具，如 CircleCI，可以连接到你的版本库，执行类似的功能。如果你想自己管理，可以使用开源工具 Jenkins。就我个人而言，我使用 Bitbucket Pipelines 的经验最多，而且非常满意。

自动构建流程有一个很酷的功能，那就是可以在没有电脑和合适工具的情况下做一些小改动。由于自动构建流程具备执行构建所需的一切功能，因此您实际上可以通过网络直接在版本库中进行简单的更改，然后让自动构建系统构建最终产品。虽然这并不是自动构建流程最令人兴奋的结果，但如果开发人员无法访问自己的电脑时需要进行一些小改动，自动构建流程有时就会派上用场。

持续集成/部署

自动化构建还允许执行对开发团队非常有益的其他任务，即 CI/CD。CI/CD 是 "持续集成/持续部署 "的缩写，是可以添加到自动化构建流程中的两项任务。持续集成指的是在自动构建过程中自动执行测试并报告测试结果的能力。这样做的目的是对开发流程进行检查，确保至少在某些分支上，开发人员不会检入导致测试失败的代码，从而给项目中的其他开发人员带来问题。基本上，它可以持续测试开发人员的协作结果，并在出现问题时通知所有人。

持续部署允许您从构建系统中进行全面部署，无论是部署到网站还是应用程序商店。 就我个人而言，我不喜欢构建系统本身执行部署，但我倾向于让构建系统为项目的部署做好准备，这样我只需点击一个按钮或执行一个命令就能让一切正常运行。例如，对于发布到亚马逊网络服务（Amazon Web Services）的网络项目，我喜欢让持续部署流程为生成的网络应用程序构建一个 docker 镜像，然后将其发送到亚马逊的容器存储库（Container Repository），并标注发布版本。然后，我只需为容器任务更改映像的名称，就能启动部署流程。请注意，我还将亚马逊配置保存在版本控制中，这样我就能记录哪些版本在何时发布。

总之，自动化构建流程可以实现开发管道的标准化和系统化。这就迫使开发团队将构建流程的所有步骤明确化、可重复化，并对每个版本的软件进行审计。使用自动化构建系统能迫使开发人员以 "正确 "的方式发布产品，而不走弯路，同时为开发人员和组织增加优势。无论您的开发组织是一个人还是一个大型团队，自动化构建流程都能为您的组织带来诸多好处。