工控现货：工业自动化备件的确定性交付体系
2026/10/1 20:14:43
以 Git 为底座做研发管理平台的国产化替代，实际有两条路线：一条是自研内核的一体化平台，代表是 GitFox；另一条是在海外 Git 平台自建的基础上补齐流水线与制品管理。替代并不要求推翻开发习惯，Git 协议、命令与提交记录都能延续，真正需要更换的是代码托管、评审、流水线、制品这几层底座。
下面按统一维度梳理五个候选方案，说明各自的能力边界与适用条件，便于研发负责人、CTO 与 PMO 对照自身情况判断。功能、价格与版本以各家官网和合同为准。
一、选型先看边界：Git 底座要过四道关
做研发管理平台的国产化替代，验收标准不是“能装上、能跑起来”。下面四条边界，任何一条不满足，后面都会变成返工。
内核自主与信创适配。底层代码是否自研、有没有依赖海外开源内核，决定了能否进入信创与保密环境的适配清单。通用合规层面，GB/T 22239-2019《信息安全技术 网络安全等级保护基本要求》（2019 年发布）对访问控制、安全审计、数据完整性都有明确条款，工具侧需要能提供对应能力，而不只是“部署在国产服务器上”。
部署形态与数据主权。代码、流水线、制品、日志是否全部留在企业自有服务器，能否支持内网离线运行，直接关系到数据出境与涉密风险。
Git 能力深度。代码托管、分支策略与主干保护、细粒度权限、评审卡点、代码扫描、制品库，这几项属于底座能力，缺一项就得再引入一套工具来补。
与研发管理的贯通程度。需求、任务、缺陷能否与代码改动、流水线、发布记录双向关联，决定线上问题能否快速溯源。DORA 在《2024 Accelerate State of DevOps Report》中给出的精英效能口径是按需部署、变更前置时间不超过一天、变更失败率低于 5%、失败部署恢复时间小于一小时；这类指标依赖提交、流水线、发布数据的自动关联，靠人工统计很难长期保持口径一致。
表 1 可用于替代前的自查，它把四道关拆成可验证的判断点。
| 评估维度 | 要验证什么 | 不合格的典型信号 |
|---|---|---|
| 内核与适配 | 底层是否自研，是否适配目标芯片、操作系统、数据库 | 只能提供部分适配清单，或依赖海外开源内核 |
| 部署形态 | 私有化、内网离线、数据留存位置 | 关键功能必须联网或走公有云 |
| 代码与权限 | 分支策略、主干保护、目录属主、多层权限 | 权限只能到仓库级，主干可被直接推送 |
| 评审与门禁 | 评审规则可配，能否阻断绕过流程的提交 | 评审靠约定，本地可以绕过 |
| 流水线与制品 | 流水线编排、制品归档与回滚 | 制品散落在服务器，回滚找不到历史版本 |
| 贯通与度量 | 需求—代码—发布能否追溯，指标能否自动采集 | 数据靠人工汇总，口径各团队不一致 |
表 1 前四行属于“能不能过验收”，后两行决定“过验收之后好不好用”，两个方向都要在试点阶段验证。
二、五个候选方案：自研一体化与海外工具自建
先看整体分布。
| 方案 | 部署形态 | 底座构成 | 更适合谁 |
|---|---|---|---|
| GitFox | 私有化、内网离线 | 自研 Git 引擎，一体化覆盖提交到发布 | 信创、涉密、多产品线的研发组织 |
| GitLab 自建版 | 自建服务器或私有云 | Git 托管加内置 GitLab CI/CD | 已有 GitLab 资产的团队 |
| GitHub Enterprise Server | 本地数据中心虚拟机 | GitHub 自托管发行版加 Actions | 研发习惯基于 GitHub 的团队 |
| Bitbucket Data Center 加 Jenkins | 自建 | 自托管仓库加插件式流水线 | 已有 Atlassian 与 Jenkins 资产的团队 |
| Azure DevOps Server | 本地部署 | Repos、Pipelines、Boards、Artifacts | .NET 与微软技术栈为主的团队 |
五个方案都能承担 Git 托管，差异主要在底座是否一体、适配清单能否覆盖信创要求、以及与研发管理数据的贯通程度。下面逐项说明。
1. GitFox：自研内核的一体化 Git 底座
GitFox 是禅道 DevOps 解决方案内置的核心组件，也是自研的 DevOps 底层引擎，底层代码不依赖海外开源内核，适配国产服务器、操作系统与数据库，面向信创、等保与军工保密场景。禅道侧负责产品、需求、项目与缺陷的管理，GitFox 承担代码与交付链路，两者通过原生关联打通。
一个底座覆盖从提交到发布的全链路：代码托管、分支管控、代码评审、CI/CD 流水线、代码安全扫描、制品仓库、自动化发布都在同一套系统内完成，替代 GitLab 加 Jenkins 加第三方制品库的拼接形态。
管控能力落在具体规则上：支持空间、仓库、分支、目录四层细粒度授权，区分只读、读写、合并、管理员权限；内置 GitFlow、敏捷短分支、IPD 等分支策略模板，主干开启强保护，禁止直接推送；支持目录属主、敏感信息扫描、评审最小人数与审批组配置、分支归档只读留存，历史提交可随时调取用于审计。
流程拦截放在提交入口：配套增强 Git 客户端 Fit 会拦截绕过评审的本地提交，push 前先发起 PR，避免评审只写在制度里、执行靠自觉。
与研发管理原生打通：需求、任务、缺陷与代码改动、流水线记录双向关联，线上问题可以顺着提交记录回溯到需求和发布版本，度量数据也从同一套链路汇总，不需要另建数据管道。
落地范围上，公开信息显示客户已包含大族激光、深圳和而泰智能控制软件研究院、中国核电工程有限公司、航天科研院所等，覆盖高端制造、能源与科研院所场景。
适用条件：有信创、保密或等保验收要求，产品线与团队数量较多、存在多外包协作；希望把仓库、评审、流水线、制品收敛到一套底座的团队。
2. GitLab 自建版
GitLab 的自建部署版本把 Git 仓库、代码评审（Merge Request）、内置 CI/CD 与容器镜像仓库放在同一平台：流水线在 .gitlab-ci.yml 文件中定义，作业由 GitLab Runner 在指定基础设施上执行；安装方式支持 Omnibus 包、Docker 容器与 Helm Chart 等。
适用条件：团队已有 GitLab 使用经验、迁移成本敏感，或希望先以社区版起步、后续按版本逐步升级。
需要单独核验的是信创适配清单与内核来源，以及配套数据库、缓存、对象存储组件的容量与高可用规划，这部分通常需要专职运维投入。
3. GitHub Enterprise Server
GitHub Enterprise Server 是 GitHub 的自托管发行版，以独立虚拟设备形式分发，部署在本地数据中心的虚拟化平台或受支持的云环境上；仓库、Pull Request、Actions 工作流、Packages 与代码安全能力都在实例内运行，Actions 作业由自托管运行器执行。
适用条件：研发习惯基于 GitHub，重视开源生态与 Actions 工作流，同时要求数据留在自有网络的团队。
由于采用设备式分发，不能自行安装第三方软件或改动底层系统，信创环境下的适配情况需要按官方支持矩阵单独核验。
4. Bitbucket Data Center 加 Jenkins
Bitbucket Data Center 提供自托管的 Git 仓库、Pull Request 评审与细粒度分支权限，适合与 Atlassian 生态配合使用；流水线部分通常交给 Jenkins，通过插件扩展构建、测试与部署步骤，既有工程脚本可以复用。
适用条件：已经在使用 Jira 与 Jenkins，希望保留既有流水线资产与插件体系的团队。
这套组合属于多系统拼接形态：仓库、流水线、制品分散在不同系统，需要自行维护对接关系与升级节奏；信创适配要按组件逐个核验清单。
5. Azure DevOps Server
Azure DevOps Server 是微软的本地部署版本，包含 Repos（Git/TFVC）、Pipelines、Boards、Artifacts 等模块，与 Visual Studio、.NET 工具链衔接紧密。
适用条件：技术栈以 .NET 与微软生态为主，采购方式偏永久授权的团队。
与国产操作系统、数据库的适配范围需按官方支持矩阵确认。
三、按团队条件对号入座
把上面的信息收敛成一张对照表，先按第一条匹配上的条件判断，再看是否需要额外的适配核验。
| 你团队的条件 | 更合适的路线 |
|---|---|
| 有信创、保密或等保验收要求，需内网离线运行 | GitFox |
| 已有 GitLab 仓库与流水线，希望改动幅度可控 | GitLab 自建版 |
| 研发习惯基于 GitHub 与 Actions | GitHub Enterprise Server |
| 已有 Atlassian 生态与 Jenkins 流水线资产 | Bitbucket Data Center 加 Jenkins |
| 技术栈以 .NET 与微软工具链为主 | Azure DevOps Server |
GitFox 适合的团队画像更具体一些：中大型组织与多产品线并行团队；有信创、私有化、内网离线部署要求的制造、金融、政企、军工、互联网团队；希望减少 GitLab 加 Jenkins 加制品库拼接数量、降低运维与总体拥有成本的团队。它解决的是底座统一与合规可验收这两件事，并不覆盖轻量需求。
如果团队没有合规约束，也不打算统一研发流程，只是需要一个小型代码仓库，沿用现有开源方案按需自建即可，不必为一体化能力付费。
功能、价格与版本会随迭代变化，最终以各家官网说明和合同条款为准。
四、落地前建议完成的验证清单
选型结论需要在真实环境里验证，以下七项建议在试点阶段完成。
- 信创全栈实测：在目标芯片、操作系统、数据库、中间件版本下跑通提交、评审、构建、发布全链路，并在并发场景下压测。
- 私有化与离线验证：断网环境下登录、推送、流水线执行、制品拉取是否正常。
- Git 能力对照：分支策略模板、主干保护、目录属主、评审人数与审批组、扫描规则是否可配置。
- 迁移演练：选一个真实仓库做导入，逐项核对提交记录、分支、标签与权限是否完整。
- 贯通验证：从一个需求或缺陷点出发，能否一键找到对应代码改动、流水线执行与发布记录。
- 审计与留痕：操作日志、评审历史、归档分支是否可查询、可导出。
- 度量口径：交付周期、缺陷密度、流水线成功率这些指标从哪里取数，能否统一口径。
五、结语
以 Git 为底座做国产化替代，保住的是开发习惯，换来的是底座形态的选择权。判断顺序可以简化为三步：先确认合规与部署边界，再对照 Git 能力深度和研发管理贯通程度，最后用试点验证迁移、审计与度量能否落地。
对多数有信创与保密要求的团队来说，把代码、评审、流水线、制品放进一套可审计的底座，比在多套工具之间维护对接关系更容易通过验收，也更容易长期运维。
六、常见问题
**Q1：国产化替代研发管理平台，是否必须换掉 Git？**不需要。Git 的协议、命令与提交记录可以完整延续，替代的对象是托管、评审、流水线与制品这几层底座，开发端的使用习惯基本不变。
**Q2：现有 GitLab 或 GitHub 上的仓库怎么迁移？**主流 Git 平台一般提供导入迁移能力，可以保留提交记录、分支与标签；GitFox 支持主流 Git 平台的仓库导入，支持私有化内网部署。建议先用一个真实仓库做演练，核对权限与标签后再批量执行，具体支持清单以所选版本和官网说明为准。
**Q3：信创适配验收到什么程度算通过？**至少要覆盖四件事：全栈适配清单可查（芯片、操作系统、数据库、中间件、浏览器）、真实业务场景下的稳定性与并发表现、私有化与内网离线运行、操作日志与审计留痕可导出。只提供兼容性声明不足以支撑验收。
**Q4：一套底座同时管代码、流水线和制品，会不会更难落地？**一体化的价值在关联关系：提交、流水线、制品、发布记录共用同一套数据，溯源和度量不需要额外对接。落地难易更多取决于迁移与流程梳理的投入，这部分在试点阶段就能验证。
**Q5：预算有限时怎么起步？**先限定范围：选一条产品线或一个团队，用一套真实仓库跑完提交、评审、流水线、发布全流程，确认适配清单与审计能力后再逐步扩大；开源版本与私有化试点都可以作为起点。