论文技术总结：COBOL 的便携式与安全 CI/CD——来自工业迁移的教训

1. 研究背景与问题 (Problem)

背景：
Bankdata 是丹麦银行的合作 IT 服务提供商，其核心系统基于运行在 IBM 大型机上的遗留 COBOL 应用程序。在受监管的金融行业，CI/CD（持续集成/持续交付）流水线对于确保系统稳定性、合规性和安全性至关重要。

核心问题：
原有的 Jenkins 基于 Groovy 脚本的 COBOL CI/CD 流水线存在严重的技术债务，具体表现为：

• 架构脆弱且耦合度高： 流水线逻辑分散在四个相互依赖的仓库中（模板、Worker、工具、配置），且深度耦合于 Jenkins 特定的 API 和函数（如 container, withEnv, currentBuild 等）。
• 运行时依赖管理低效： 关键依赖（如 COBOL Expander）在流水线运行时动态安装，导致环境不一致、执行时间长且维护成本高。
• 供应商锁定 (Vendor Lock-in)： 过度依赖 Jenkins 使得迁移到其他 CI/CD 平台极其困难，限制了组织的灵活性。
• 安全与合规风险： 运行时安装依赖和复杂的配置增加了安全漏洞的风险，且难以满足金融行业严格的审计要求。
• 性能瓶颈： 流水线执行缓慢，平均运行时间长达 724 秒，严重拖慢了开发反馈循环。

2. 方法论与迁移策略 (Methodology)

研究团队将流水线从 Jenkins 迁移至 GitHub Actions，并采用了容器化架构和抽象层设计。主要策略包括：

A. 解耦与抽象层 (Decoupling & Abstraction)

• 平台逻辑抽象： 识别并提取所有 Jenkins 特定的函数（如环境管理、状态报告、文件操作），将其封装在一个独立的 Groovy 包中。
• 翻译层 (Translation Layer)： 创建一个中间层，将流水线核心逻辑与底层 CI/CD 平台（Jenkins 或 GitHub Actions）隔离。核心逻辑仅调用抽象层函数，而非直接调用平台 API。
• 重构环境管理：
  • 移除对 Jenkins currentBuild 对象的依赖，改用环境变量或 Git 命令获取元数据。
  • 用标准 Groovy 的 println 和 try-catch 替换 Jenkins 特定的 echo、error、catchError 等状态报告函数。
  • 将 Shell 脚本执行封装为通用的 Groovy 函数（使用 ProcessBuilder），并自定义凭据处理逻辑以替代 withCredentials。

B. 容器化与依赖优化 (Containerization)

• 预构建 OCI 镜像： 创建一个包含所有必要工具（Groovy, GnuCOBOL, COBOL Expander, COBOL Check, Zowe CLI, Node.js 等）的预构建容器镜像。
• 消除运行时安装： 所有依赖在镜像构建阶段安装，流水线运行时直接复用，消除了动态安装带来的延迟和不一致性。
• 镜像瘦身： 通过一系列优化步骤（如从 Debian 切换到 Alpine 基础镜像、移除构建依赖、清理缓存、使用特定版本的 JDK 等），将镜像大小从 1.4 GiB 减少至 559 MiB（减少 60%）。

C. 仓库结构简化

• 将原本分散在四个仓库的逻辑合并为一个统一的仓库，简化了依赖管理和代码导航。
• 利用 GitHub Actions 的机制（如 CODEOWNERS、预接收钩子）强制执行应用代码与流水线逻辑的分离。

3. 关键贡献 (Key Contributions)

1. 受监管环境下的迁移蓝图： 提供了一份在严格合规要求（金融、大型机）下，将遗留 CI/CD 流水线从 Jenkins 迁移到现代容器化架构的详细端到端方案。
2. 平台无关的抽象模式： 验证了通过抽象层隔离平台特定逻辑的有效性，使得核心流水线逻辑可以在不同 CI/CD 平台（Jenkins, GitHub Actions）间无缝迁移，显著降低了供应商锁定风险。
3. 遗留系统的现代化实践： 展示了如何在保留 COBOL 核心业务逻辑不变的前提下，通过容器化和 DevOps 实践提升大型机生态系统的可维护性和性能。
4. 技术与组织的双重评估： 不仅提供了量化的性能数据，还结合利益相关者的定性反馈，探讨了技术迁移中的组织文化、开发者体验和安全性挑战。

4. 实验结果 (Results)

定量指标

• 执行时间大幅降低： 流水线平均运行时间从 724 秒 降至 130 秒，减少了 82.1%。
• 镜像体积优化： 容器镜像大小减少了 60%（1.4 GiB -> 559 MiB），显著提升了构建速度和传输效率。
• 稳定性提升： 通过预构建镜像消除了运行时依赖安装的不确定性，执行环境更加可复现。

定性反馈

• 可维护性： 代码库结构简化，单一仓库降低了认知负荷，新成员上手更容易。
• 安全性： 依赖项被预审查并固化在镜像中，配合更严格的密钥管理策略，提升了整体安全态势。
• 用户体验挑战： 开发者反馈 GitHub Actions 的界面在步骤级可视性上不如 Jenkins 细致，且部分 COBOL 开发者对 Web 界面感到不适应（建议通过 VS Code 插件缓解）。
• 技术栈选择： 继续使用 Groovy 而非 YAML 编写流水线逻辑，虽然增加了学习门槛，但保证了跨平台逻辑的连续性和独立性。

5. 意义与启示 (Significance)

• 行业示范效应： 证明了即使是高度受监管、依赖数十年历史遗留技术（COBOL/大型机）的金融机构，也能成功实施现代化的 CI/CD 流程，而无需牺牲合规性或系统稳定性。
• 通用架构原则： 提出的“抽象层 + 容器化”模式不仅适用于 COBOL，也适用于其他存在紧密耦合和运行时依赖安装问题的遗留系统或现代技术栈。
• DevOps 文化融合： 强调了在技术迁移过程中，必须尽早让遗留系统开发团队（COBOL 开发者）参与，平衡架构的纯粹性与实际可用性，以确保变革的顺利落地。
• 安全与速度的平衡： 展示了通过预构建和依赖固化，可以在提升构建速度的同时，增强供应链安全和审计能力，打破了“安全即慢”的刻板印象。

局限性：
研究主要验证了在 GitHub Actions 上的表现，未能在多个 CI/CD 平台进行广泛的通用性测试；且由于组织政策限制，连续部署（CD）场景未在真实生产环境中验证。

总结：
该论文通过 Bankdata 的实际案例，成功展示了一种将脆弱、慢速且高度耦合的 Jenkins COBOL 流水线转化为快速、安全且平台无关的容器化架构的方法。其核心在于抽象层设计和容器化依赖管理，为同类工业场景的现代化改造提供了宝贵的经验和可复用的蓝图。