问题描述
在搜索引擎中无法找到关于”build step”的解释，想知道这个术语的含义。他还希望能够找到一个开发人员术语索引，以便更好地理解这个术语。
解决方案
方案1
在CI/CD（持续集成/持续交付）流水线中，”build step”可以是任何你想要的东西。它相当于传统编程语言中的函数或过程。在CI/CD环境中，”build step”的示例包括：
– 设置一个干净的构建或测试环境，例如启动实例、启动数据库、加载数据等。
– 从GitHub、GitLab等获取代码。
– 编译应用程序的组件。
– 将上一个构建步骤的产物发送到存储库。
需要注意的是，在CI/CD世界中，”build step”不一定是构建任何东西，而可能是准备要构建的东西或对构建的产物进行某些操作。
方案2
根据上下文，”build step”的确切含义会有所不同。但从高层次来看，它通常与部署过程相关。”build step”就是在部署步骤之前的步骤。
基本上，构建过程包括使应用程序完全准备好（编译、链接、上传产物等），以便我们可以继续将其部署到最终提供请求的Web服务器/容器中。
方案3
在大型机（也称为主机）世界中，”build step”通常是一个由至少两个步骤组成的过程：
1. 第一步使用程序源代码（由开发人员使用任何编程语言编写，如COBOL、C、FORTRAN、PL1、汇编语言等）作为输入，然后将该输入转换为目标模块（还不是可执行文件…）。这个转换通常由称为”编译器”的程序完成（每种编程语言可能有无数版本的编译器，例如COBOL有COBOL VS、COBOL LE、COBOL 2等）。
2. 第二步使用目标模块（来自第一步的输出）将其转换为可执行程序，例如通过静态链接（调用）子程序。这个转换通常由称为”链接器”的程序完成。
完整的编译步骤和链接步骤通常捆绑在一起，以某种脚本（过程）的形式存在，主机上通常使用JCL（如果批处理中进行编译/链接）或REXX（如果在线进行编译/链接）来完成。这个脚本实际上就是所谓的”构建过程”。
在上述情况下，去查看其他操作系统，你也会发现类似的编译器和链接器。
需要注意的是，构建过程的结果（可执行文件）通常存储在某种工作区域（如临时文件夹）中。在将其用于执行可执行文件之前，仍然需要将其发送（复制、FTP等）到其他位置（例如授权文件夹或库），这就是可执行文件的部署过程（与构建可执行文件相比）。
最好不要直接将部署目标作为构建过程的输出（如果这样做，你基本上会向任何开发人员开放生产环境，这对于银行或在飞行中修复某些软件的情况来说是不可取的）。
方案4
在Docker环境中，”build step”可以根据具体情况而定。如果按照字面意思理解，你可以将”build”步骤定义为包含构建实际镜像所需的所有步骤。但是，阶段名称并不遵循任何命名约定。因此，”build”可以是你想要的任何内容。