为什么要自动执行构建和部署流程？
在研究构建自动化涉及的内容之前，先来思考为什么自动化构建管理流程如此重要。
如果您在 IDE 中工作，通常可以使用键盘快捷键触发构建，那么为什么还要自动化该过程？
对于初学者来说，当您想对工作进行健全性检查或向老板快速演示时，在本地构建相当方便，但为 CI/CD 管道使用本地构建并不是良好做法。
使用专用的构建服务器可确保干净的环境，这将快速标记丢失的依赖项，防止输出被部署到测试环境时出现问题和延迟。
如果没有自动化构建启动管道中的其他阶段，CI/CD 的可靠性将大幅降低。 如果您必须记得登录构建服务器并启动每个构建（包括所有测试），在失败情况下照看流程，然后将输出移动到工件仓库以便将其部署到测试，那么您的流程很容易出错。
虽然可以推迟构建等待更多待测试更改，但这样会损害 CI/CD 的效益。
最后，CI/CD 管道背后的策略是快速失败。
越早发现问题，就越容易修正，构建自动化流程也就越高效。 自动化构建阶段比手动触发步骤更快，并且比手动移动文件和运行测试快得多。
通过自动化构建，您可以确保在每一次提交（或一批提交）时以正确的顺序执行所有步骤，并在节省时间的同时获得快速反馈的收益。
在您的 CI/CD 管道中，构建自动化如何运作？
如果您刚接触 CI/CD，那么设置自动构建并在团队中有人提交更改时进行触发是您需要做的第一件事（在将所有内容纳入源控制之后）。 您应该已经拥有了一个构建脚本或定义文件，可能是由您的 IDE 提供，也可能是由您自己编写。
如果没有，则需要为您使用的语言选择合适的构建自动化工具，并指定待编译、链接和打包的文件。 然后，您可以使用 CI 服务器协调各个步骤：从初始触发到提供反馈以及定义失败条件。
触发构建
自动持续集成涉及在每次向 master 提交后触发构建，以在每一次更改后立即集成和测试。 如果构建成功，则触发流程的下一步。
大多数 CI 工具允许您为构建配置额外的触发器并自定义后续管道阶段。
例如，当对特定目录中的分支进行提交时，您可能希望触发相同的一组步骤。 另一方面，在使用部署工具的帮助下，您可能希望安排一个夜间构建，通过额外的测试层用于刷新暂存环境。 您也可以手动启动构建阶段。
运行构建
良好的做法是在专用构建服务器上而不是在您的开发机器上运行构建步骤。 在干净的环境中构建将标记缺失的依赖项，并避免“在我的机器上能用”这样的问题。
构建步骤本身会调用您选择的构建自动化工具（例如 Maven、Ant 或 Gradle），执行构建脚本或定义文件中指定的任务。
只要您了解构建运行所需的时间，即可使用部署工具为没有在指定时间内完成的构建配置失败条件。 这种做法避免了长时间运行的构建阻塞资源。
执行测试
除了为部署准备代码之外，自动化构建管理流程也是对代码运行许多其他检查（如单元测试、linting 和静态代码分析）的理想位置。 在使用部署工具的帮助下为每个构建中运行检查并在出现问题时加以解决，有助于提高代码质量。
尽管这些检查在生成构建工件之前运行，但失败不一定需要停止管道的其余部分。 例如，虽然发现了 linting 错误，但您可能依然决定发布构建工件并进入下一个管道阶段。 配置质量阈值有助于防止“小”问题随着时间推移而累积。
发布构建工件
自动化构建过程的输出是构建工件，其中可能包括安装程序、WAR 文件、库和容器。 将这些文件发布到工件仓库为您了提供一个中心位置，您可以从中将构建部署到不同的环境，最好是在使用部署工具的帮助下。
在构建之后，CI/CD 管道的下一阶段通常涉及自动化功能测试，这需要将构建部署到一个或多个测试环境（有时与其他组件一起，例如数据库或其他微服务）。 如果这些测试成功完成，则可以使用相同的构建刷新暂存环境并最终发布上线。
指标和反馈
您可以从 CI 工具查看构建阶段的结果，包括构建是否成功创建以及单元测试和其他检查的结果。 配置警报通知失败可让您快速做出反应并使代码恢复到可发布状态。
部署工具还将整理来自管道的数据用于趋势分析。 检查构建历史和指标，如构建持续时间、成功率和代码覆盖率，可以提供有助于改进 CI/CD 流程的信息。