3. CI/CD基础与仿真场景适配

在软件工程中，CI/CD 是一组围绕“频繁集成、可重复构建、可验证交付”建立起来的工程实践。它并不是某个具体工具的别名，而是一条从代码提交到可运行产物的自动化链路。理解这条链路的三个核心概念，是判断仿真任务能否、以及如何接入 CI/CD 的前提。

持续集成、持续交付、持续部署的核心原则

持续集成（Continuous Integration，CI）的核心原则是：开发者频繁地把代码合入主干，每次合入都触发一次自动构建与自动化测试，尽早暴露集成错误。它的关键不在于“自动”，而在于“频繁”和“可验证”——如果一次合入后没有任何客观的通过/失败判定，那只是自动构建，不是持续集成。典型 CI 流水线包含：拉取代码 → 依赖安装 → 编译/构建 → 单元测试 → 静态检查 → 产出构建物。

持续交付（Continuous Delivery，CD）在 CI 之上增加一层：保证主干上的每一次通过 CI 的构建，都处于“可随时发布到生产”的状态。它要求构建物可追溯、可复现，部署过程自动化，但发布动作仍由人决定。也就是说，持续交付把“能不能发布”变成常态，把“什么时候发布”留作业务决策。

持续部署（Continuous Deployment）则更进一步：只要通过全部质量门禁，就自动发布到生产环境，无需人工审批。三者的关系可以概括为：CI 是基础，持续交付是“随时可发布”，持续部署是“自动发布”。很多团队实际做到的是持续交付而非持续部署，这是完全合理的工程选择。

三者共同依赖几条底层原则：单一可信源（代码仓库）、构建物不可变、环境一致性、质量门禁前置、失败快速反馈。这些原则与具体语言、框架无关，也正是判断仿真任务能否适配的标尺。

仿真任务与软件构建的差异分析

把仿真任务直接塞进为软件构建设计的流水线，往往会“跑得起来但用不起来”。原因在于二者在多个维度上存在本质差异，下面这张图对比了软件构建与仿真任务在流水线中的关键特征差异。

从图中可以看出，差异集中在五个方面。第一是执行时长：软件构建通常在秒到分钟级，适合每次提交触发；而一次 CFD 或结构仿真可能跑几十分钟到数小时，若每次提交都全量跑，流水线会被拖垮。第二是资源需求：仿真往往需要 GPU、大内存和商业求解器许可证，普通构建节点无法承载。第三是结果确定性：软件测试是布尔判定，仿真因浮点运算、迭代收敛和并行归约顺序不同，同一输入也可能产生微小数值差异，必须用容差而非精确相等来判定。第四是通过标准：仿真关注的是物理量误差、收敛性和趋势是否合理，而不是“测试是否全绿”。第五是产物形态：仿真结果文件动辄 GB 级，不适合直接塞进常规构建产物仓库。

仿真场景接入 CI/CD 的适配策略

基于上述差异，仿真接入 CI/CD 不能照搬软件流水线，而应做针对性设计。首先是分级触发：把仿真用例按耗时和重要性分层。快速冒烟用例（如简化模型、粗网格、单工况）在每次提交时运行，控制在几分钟内；完整工况集在夜间或发布前触发。这样既保留了持续集成的快速反馈，又不牺牲覆盖度。

其次是容差判定。不要用“结果完全相等”作为通过条件，而应定义参考基准与允许偏差。例如对某个监测点的位移，可设定相对误差不超过 2%、绝对误差不超过 0.05 mm 即判定通过；对收敛性，可要求残差在指定迭代步内降到 1e-4 以下。判定逻辑应写成脚本，输出明确的通过/失败与偏差数值，便于在流水线中作为质量门禁。

第三是专用执行器与许可证管理。仿真任务应调度到带求解器和许可证的执行节点，并在流水线中处理许可证排队与超时。常见做法是把求解器调用封装成容器镜像或脚本入口，由 CI 系统按标签选择执行器。

第四是大产物外置存储。结果文件不进入构建产物仓库，而是上传到对象存储，流水线中只保留结果摘要、关键曲线和判定报告。这样既控制仓库体积，又保留可追溯性。

下面给出一份可直接参考的仿真 CI 任务配置示例，展示分级触发与容差判定的落地方式：

# 仿真 CI 任务示例（伪配置，参数为教学示例）
stages:
  - smoke_sim      # 每次提交触发，粗网格单工况
  - full_sim       # 夜间/发布前触发，完整工况集

smoke_sim:
  trigger: on_commit
  executor: sim-node-cpu
  solver: openfoam
  mesh: coarse
  cases: [case_A]
  timeout: 10m
  judge:
    metric: outlet_velocity
    ref: 12.40          # 参考值（示例）
    rel_tol: 0.03       # 相对容差 3%
    abs_tol: 0.05
  artifacts:
    report: smoke_report.json
    upload: false       # 小结果随流水线保留

full_sim:
  trigger: schedule     # 夜间批跑
  executor: sim-node-gpu
  solver: openfoam
  mesh: fine
  cases: [case_A, case_B, case_C]
  timeout: 4h
  judge:
    metric: drag_coefficient
    ref: 0.312
    rel_tol: 0.02
    convergence: {residual: 1e-4, max_iter: 2000}
  artifacts:
    report: full_report.json
    results_bucket: s3://sim-results/run-${CI_PIPELINE_ID}

这份配置体现了几个关键点：冒烟任务用粗网格和单工况换取速度，完整任务用细网格和多工况换取覆盖度；判定用参考值加相对/绝对容差，而不是精确相等；结果文件上传到对象存储，流水线只保留报告。实际参数需根据具体模型和求解器标定，上述数值仅为教学示例。

需要强调的是，仿真接入 CI/CD 的目标不是“把所有仿真都自动化”，而是把可重复、可判定、值得频繁验证的那部分仿真纳入流水线，让回归问题尽早暴露。对于探索性、一次性的仿真分析，保留人工执行反而更合理。理解 CI/CD 的核心原则与仿真任务的差异，正是做出这种取舍判断的基础。