📚 课程目录第4章构建自动化基础

4. 构建自动化基础

在医疗软件工程中，构建不是“把代码编译一下”这么简单。它承担着把源代码、依赖、配置、资源、编译参数和签名材料，稳定地转换成可测试、可追溯、可发布的软件制品这一关键职责。医疗软件往往需要满足 IEC 62304、FDA 或 NMPA 对软件生命周期、配置管理和可追溯性的要求，因此构建过程本身必须被工程化、版本化、可审计。本章围绕构建工具选型、构建脚本编写、构建产物管理和可重复构建与确定性构建展开，重点说明“实际怎么做”以及“为什么在医疗软件中必须这样做”。

一、构建工具：按技术栈选择，而不是按喜好选择

构建工具的核心职责包括：依赖解析、编译、资源处理、测试执行、打包、版本标记和产物输出。医疗软件项目常见的技术栈决定了工具选择：

Maven：基于 POM 的声明式构建，生命周期固定（validate、compile、test、package、verify、install、deploy），依赖传递和仓库管理成熟，适合 Java 医疗后端、服务端和 Android 库项目。其“约定优于配置”的特性使构建脚本更易审计。
Gradle：基于 Groovy/Kotlin DSL 的灵活构建，支持增量构建和构建缓存，适合 Android 医疗应用、多模块微服务以及需要自定义构建逻辑的项目。但灵活性也意味着脚本需要更严格的评审和锁定。
CMake：跨平台 C/C++ 构建系统生成器，适合医疗设备嵌入式软件、影像处理算法库和需要同时支持 Windows/Linux 的本地代码。它生成 Makefile 或 Visual Studio 工程，本身不直接编译。
MSBuild：.NET 生态的构建引擎，适合 C# 医疗信息系统、WPF 客户端和基于 .NET 的服务。与 Visual Studio 深度集成，支持条件编译和发布配置。

选型时应优先考虑团队技术栈、依赖生态、可重复构建能力和审计友好度，而不是单纯追求“新”或“快”。例如，一个需要长期维护的 Java 医疗后端，Maven 的固定生命周期和显式依赖树往往比 Gradle 的灵活脚本更容易通过法规审计。

二、构建脚本编写：把“人脑记忆”变成“机器可执行”

构建脚本是构建过程的唯一事实来源。医疗软件要求构建脚本与源代码一同纳入版本控制，任何构建参数变更都必须经过评审。编写构建脚本时，应遵循以下原则：

显式声明依赖版本：禁止使用动态版本（如 1.2.+ 或 LATEST），必须锁定到具体版本，并配合依赖锁定文件（如 Gradle 的 gradle.lockfile、Maven 的 dependencyManagement）。
固定编译器和工具链版本：在脚本中指定 JDK、NDK、MSBuild 工具集版本，避免“同代码不同机器编译结果不同”。
参数化环境差异：通过 profile、property 或环境变量区分开发、测试、生产配置，但不得把密钥、证书密码硬编码在脚本中。
集成质量门禁：在构建脚本中绑定单元测试、静态分析、覆盖率检查，构建失败即阻断，而不是“先构建后补测”。

下面是一个 Maven 构建脚本的关键片段示例，用于医疗后端服务：

<properties>
  <maven.compiler.source>17</maven.compiler.source>
  <maven.compiler.target>17</maven.compiler.target>
  <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
</properties>

<build>
  <plugins>
    <plugin>
      <groupId>org.apache.maven.plugins</groupId>
      <artifactId>maven-surefire-plugin</artifactId>
      <version>3.2.5</version>
      <configuration>
        <argLine>-Duser.timezone=UTC</argLine>
      </configuration>
    </plugin>
  </plugins>
</build>

该片段固定了 JDK 17、UTF-8 编码和测试时区为 UTC，减少因环境差异导致的构建漂移。对于 CMake 项目，则应在 CMakeLists.txt 中显式设置 CMAKE_CXX_STANDARD 和 CMAKE_BUILD_TYPE，并避免使用 file(GLOB ...) 自动收集源文件，因为文件顺序和新增文件会破坏可重复性。

三、构建产物管理：从“能跑”到“可追溯”

构建产物（artifact）包括可执行文件、库文件、安装包、容器镜像、符号表、测试报告和构建日志。医疗软件对产物管理的要求远高于普通项目：每个产物必须能回答“它由哪个提交、哪次构建、哪套依赖、哪个工具链生成”。

推荐做法是：

使用制品仓库（如 Nexus、Artifactory）统一存储，禁止从开发者本机直接取包发布。
产物命名包含版本号、构建号、Git 提交短哈希，例如 patient-service-1.4.2+20240521.3-a1b2c3d.jar。
为每个产物生成 SBOM（软件物料清单），记录所有直接和传递依赖及其许可证。
保留构建日志、测试报告和签名记录，保存周期应满足法规要求的软件生命周期长度。

在医疗设备软件中，构建产物还需要与需求、风险分析、测试用例建立追溯链。例如，一个输液泵控制软件的固件产物，应能追溯到对应的需求条目、风险控制措施和验证测试记录。

四、可重复构建与确定性构建：医疗软件合规的基石

可重复构建指在相同源代码、相同依赖、相同工具链和相同构建环境下，能够重新生成功能等价的产物。确定性构建更进一步，要求产物的二进制内容逐字节一致。两者在医疗软件中的意义在于：

审计与复现：监管机构或第三方审计时，能够从版本库重新构建出与发布版本一致的软件，证明发布产物确实来自受控源代码。
缺陷定位：当现场出现问题时，可以精确复现当时构建环境，排除“构建漂移”干扰。
供应链安全：确定性构建配合签名和哈希校验，可检测依赖被篡改或构建过程被注入恶意代码。

实现确定性构建的常见手段包括：固定时间戳（如 SOURCE_DATE_EPOCH）、排序文件列表、去除绝对路径、固定压缩参数、使用可复现的容器镜像作为构建环境。例如，在 Gradle 中可配置 preserveFileTimestamps = false 和 reproducibleFileOrder = true；在 CMake 中可设置 CMAKE_ARCHIVE_OUTPUT_DIRECTORY 并避免嵌入构建路径。

五、在医疗软件中的落地建议

将上述能力落地，建议从三个层面推进。第一，环境层面：使用容器或虚拟机固定构建环境，镜像本身纳入版本控制，构建节点不安装额外工具。第二，流程层面：CI 流水线中每次构建都从干净工作区开始，禁止复用上一次的中间产物；构建成功后自动上传制品仓库并生成 SBOM。第三，验证层面：定期执行“重建验证”——从同一提交重新构建，比较产物哈希；若不一致，必须定位差异来源并修复，直到哈希稳定。

示例判断依据：若某次重建产物的 SHA-256 与发布版本不一致，应优先检查：构建时间戳是否被嵌入、依赖是否被动态更新、文件遍历顺序是否变化、构建路径是否被写入二进制。修复后重新执行两次独立构建，哈希一致方可认为达到确定性构建要求。

构建自动化不是一次性任务，而是医疗软件持续合规能力的一部分。工具选型决定了下限，脚本质量决定了稳定性，产物管理决定了可追溯性，而可重复与确定性构建决定了软件在审计和现场问题复现中的可信度。把这四件事同时做好，后续的持续集成、持续交付和法规申报才有坚实底座。