3. CI/CD基础与Nextflow集成逻辑
在把 Nextflow 接入自动化部署体系之前，需要先厘清持续集成（Continuous Integration，CI）、持续交付（Continuous Delivery，CD）与持续部署（Continuous Deployment，CD）三者的边界。它们常被统称为 CI/CD，但目标、触发条件和人工介入程度并不相同。理解这些差异，才能判断一条 Nextflow 流水线应该在哪个环节自动运行、在哪个环节等待人工确认、在哪个环节直接发布。
三种“持续”的核心区别
持续集成关注的是“代码合并前后是否仍然可用”。开发者每次向主干分支推送提交，CI 系统就自动拉取代码、安装依赖、执行静态检查、运行单元测试与集成测试，并给出通过或失败的结果。它的产物是“可信的构建与测试结论”，而不是可交付的软件版本。关键特征是高频、自动、快速反馈。
持续交付在 CI 的基础上继续向前：每次通过测试的构建都会被自动打包成可部署制品（如容器镜像、压缩包、版本标签），并部署到类生产环境完成验收测试，使软件随时处于“可发布”状态。但最终是否发布到生产，仍由人决定。也就是说，持续交付保证“随时能发”，但不强制“自动发”。
持续部署则把最后一道人工闸门也去掉：只要制品通过全部质量门禁，就自动发布到生产环境。它要求极高的测试覆盖率、完善的灰度与回滚机制，以及对失败自动止损的能力。三者是递进关系，而非互斥选项。
Nextflow 为什么需要 CI/CD
Nextflow 流水线本质上也是软件：它由 main.nf、nextflow.config、模块文件、容器定义和参数文件组成，会随需求不断修改。如果只靠人工在服务器上执行 nextflow run，会暴露几类典型问题。
- 环境漂移：不同节点上的 Java、Nextflow 版本、容器运行时（Docker/Singularity）不一致，导致“本地能跑、集群报错”。
- 回归风险：修改一个 process 的输入通道或资源标签，可能悄悄破坏下游流程，人工很难每次全量验证。
- 不可追溯：某次分析结果对应哪个代码版本、哪个参数、哪个镜像标签，缺少记录，复现困难。
- 发布随意：生产流程更新依赖手工拷贝文件，容易漏改配置或误用旧版本。
CI/CD 正是用来消除这些不确定性的：把“能跑”变成“每次提交都被验证能跑”，把“发布”变成“有版本、有记录、可回滚的动作”。
Nextflow 嵌入 CI/CD 的集成逻辑
Nextflow 与 CI/CD 的集成，核心是把流水线当作一个可构建、可测试、可发布的软件制品。典型做法是：代码托管在 Git 仓库，CI 平台（GitHub Actions、GitLab CI、Jenkins 等）监听推送事件，在受控环境中执行验证，通过后构建带版本标签的制品并推送到镜像仓库或制品库，再由部署阶段拉取指定版本运行。
其中最关键的一步是用最小数据集做冒烟测试。完整生产数据动辄数十 GB，不适合每次提交都跑。实践中会准备一个极小的测试样本（例如几十条测序 reads 或几行输入表），配合 -stub-run 或专门的 test profile，在几分钟内验证流程能否正常解析、调度和产出预期文件。只有冒烟测试通过，才进入更重的验收测试或部署阶段。
下面这张图展示了从代码提交到生产运行的完整信号与制品流转关系，重点标出了三个质量门禁和人工/自动的分界点。
集成时的关键配置要点
要让上述流程稳定运行，Nextflow 侧需要做几项针对性配置。第一，用 nextflow.config 的 profile 机制区分环境，例如定义 test、staging、prod 三套参数，CI 中通过 -profile test 调用，避免把测试参数写死进主流程。第二，固定 Nextflow 与容器版本，在 CI 脚本中显式声明 NXF_VER 和镜像标签，防止“今天能跑明天不能跑”。第三，为冒烟测试准备独立的 test_data 目录和预期输出校验，用 diff 或校验和比对结果文件，把“跑完”升级为“跑对”。
# .github/workflows/ci.yml 片段（示例）
jobs:
smoke-test:
runs-on: ubuntu-latest
env:
NXF_VER: "24.04.0"
steps:
- uses: actions/checkout@v4
- name: Run smoke test
run: |
nextflow run main.nf \
-profile test,docker \
-stub-run \
--outdir results_ci
- name: Verify outputs
run: test -s results_ci/summary.tsv这段配置的含义是：在固定版本的 Nextflow 上，用 test 与 docker 两个 profile 组合，以 stub 模式快速验证流程结构，最后检查关键输出文件是否存在且非空。它不追求覆盖全部计算逻辑，而是用最低成本拦住“流程根本跑不起来”这类高频错误。