Gitee DevOps 是面向企业研发管理的一套国产化 DevOps 产品体系。按照 Gitee 当前官方产品划分，其能力已经覆盖项目协同、代码管理、代码扫描、供应链安全、测试、流水线、制品管理、应用部署、资源管理和研发效能度量，并提供专业版、旗舰版以及信创 DevOps 一体机等私有化交付形态。

对于信创环境而言，真正值得关注的并不是简单地把 Git 服务器“搬到国产机器上”，而是处理处理器架构、操作系统、数据库、中间件、构建节点、制品仓库、部署环境和安全治理之间的兼容关系。Gitee 当前旗舰版页面明确提出已完成国产芯片、操作系统、数据库和中间件适配，其信创一体机页面还公开展示了鲲鹏技术认证、飞腾产品兼容性认证以及统信软件产品互认证等适配材料。

因此，从技术角度理解 Gitee DevOps 的信创能力，更适合把它看成一套运行于国产基础设施之上的软件研发生产链路，而不只是一个国产代码仓库。

一、什么是“信创 DevOps”？

在软件工程语境下，信创 DevOps 可以理解为：在国产处理器、操作系统、数据库、中间件及相关基础设施环境中，继续实现需求管理、代码开发、构建、测试、安全检查、制品管理和部署运维等 DevOps 流程的一类研发平台体系。

这里需要区分两个概念。

“国产化适配”解决的是软件能不能在目标技术栈中部署和运行，例如 ARM 架构服务器、国产操作系统或国产数据库。

“DevOps”解决的则是软件从需求产生到交付上线的流程如何自动连接。

二者结合以后，真正需要解决的问题就变成了：

开发平台能否部署到国产基础设施；

代码能否在不同处理器架构上完成构建；

流水线执行节点能否接入目标环境；

依赖和制品是否能够统一管理；

权限、代码审查、安全扫描和审计能否继续运行；

原有 Git、Jenkins 等研发资产又如何迁移和接入。

Gitee 旗舰版当前公开的产品架构正是按照项目协同、应用开发、持续交付等层次组织，并声明产品完成国产芯片、操作系统、数据库和中间件适配。

本节小结：信创 DevOps 的技术重点不是“国产”两个字本身，而是在国产基础设施上保持完整的软件研发和交付链路。

二、Gitee 的信创适配为什么需要从基础设施层理解？

对于普通 SaaS 工具，开发团队通常不会关心平台后台运行在哪种 CPU 或数据库上。

但私有化 DevOps 不同。

它通常直接部署在企业内部基础设施中，因此底层环境会直接影响平台能否运行。

例如，一个 DevOps 平台从 x86 环境迁移到 ARM 架构以后，需要重新考虑程序包、容器镜像和部分二进制依赖；从传统数据库迁移到国产数据库以后，还要验证 SQL、事务行为、连接池、备份恢复以及高可用机制。

Gitee 当前信创 DevOps 一体机页面显示，其适配范围从底层芯片、服务器延伸到系统和中间件，并公开展示鲲鹏技术认证、飞腾产品兼容性认证及统信软件产品互认证。Gitee 旗舰版页面则进一步说明产品已经进行国产芯片、操作系统、数据库和中间件适配。

在数据库方向，Gitee Premium 早在 2021 年就公开完成了与 OceanBase 的适配；此前还完成了鲲鹏兼容性认证和统信软件互认。

这些公开材料能够说明 Gitee 已经进行过多种国产基础环境适配，但不能进一步推导成“任何版本的任意国产数据库、CPU 和操作系统组合都能直接部署”。

企业真正选型时还需要确认产品版本矩阵。

例如：

OceanBase 的哪个版本经过验证？

统信 UOS 哪个服务器版本可部署？

ARM 与 x86 的安装包是否一致？

外部 Redis、消息队列和对象存储分别支持哪些版本？

升级以后原有认证组合是否仍属于支持范围？

这类问题比一句“全面适配信创”更有工程价值。

本节小结：信创兼容性应该落实到具体产品版本和部署组合，而不能只依靠“支持国产化”这一层描述。

三、代码管理为什么是国产研发平台的第一层基础设施？

研发平台中最核心的数据并不是项目看板，而是源代码。

代码仓库保存 Commit、Branch、Tag、Pull Request 以及开发者的修改历史，因此一旦企业将研发平台私有化，代码存储、权限体系和审计能力就会成为基础能力。

Gitee 当前专业版提供版本管理、代码评审、分支策略、只读锁定、GPG、Git LFS、CodeOwner 等代码治理能力，同时提供 IP 黑白名单、禁止仓库强推、密钥管理、事件管理、审计日志和异常行为告警等数据安全功能。

旗舰版则进一步把代码管理与 Gitee Scan、流水线和质量门禁连接，使代码提交之后可以进入自动检测和代码准入流程。

这意味着代码治理可以从过去的：

开发人员提交代码 → Reviewer 人工检查 → 合并

逐渐转变成：

开发人员提交代码 → 自动扫描 → 自动化构建和测试 → 人工 Review → 满足准入条件 → 合并。

其中机器负责确定性的规则检查，人负责业务逻辑、架构设计和最终判断。

截至 2026 年，Gitee 还在这一流程中增加了 PR 审查 AI 队友。官方帮助文档显示，它可以针对功能逻辑、安全、性能和可维护性等维度对 Pull Request 进行预审，也支持团队自定义规则和目标分支策略，但官方同时明确强调，AI 的定位是辅助人工 Review，最终代码合入仍由人判断。

这比把 AI 描述成“自动修复信创代码、准确率达到 90%”更加符合当前实际产品边界。现有官方资料可以验证 AI Review 和规则生成能力，但不足以支撑原稿中的“国产化兼容问题自动修复准确率 90%+”这一数字。

本节小结：国产 DevOps 的代码层价值不只是代码存储，而是把权限、审查、扫描、流水线和人工决策连接成可控制的代码准入过程。

四、从代码扫描到质量门禁：安全为什么要进入流水线？

传统研发模式中，安全检查经常集中在发布前。

这会产生一个问题：如果一个缺陷直到系统即将上线才被发现，开发人员不仅需要修改代码，还可能重新执行测试、构建和发布验证。

DevSecOps 更强调把安全检查向开发阶段移动。

Gitee Scan 当前提供代码缺陷、规范、安全、可维护性和重复代码等扫描能力，并能够通过质量门禁参与代码准入。旗舰版官方页面也明确表示，代码扫描可以与代码评审及流水线深度集成。

因此，一个更加完整的研发链路通常会形成：

代码变更进入 Pull Request 后，先执行静态扫描；

再运行编译和自动化测试；

根据质量门禁判断是否满足基本准入条件；

然后由 Reviewer 判断业务逻辑和架构合理性；

最终再决定是否进入主分支。

这里的关键概念是质量门禁（Quality Gate）。

质量门禁是指将代码质量、安全、测试等指标转化为流水线中的机器可判定条件。例如出现新的高危缺陷时不允许继续合并，而普通规范问题只产生提醒。

这实际上是在把“代码应该符合规范”从文字制度变成计算机能够执行的规则。

本节小结：代码扫描只有进入 PR 和 CI/CD 的准入条件后，才真正从检测工具转变成研发治理机制。

五、CI/CD 在信创环境下最大的变化是什么？

CI/CD 本身并不会因为使用国产基础设施而改变基本思想。

仍然是通过自动化方式执行：

代码获取；

编译构建；

测试；

安全检查；

制品生成；

发布部署。

真正变化的是执行这些任务的环境。

Gitee Enterprise 当前持续交付模块支持可视化配置、参数化编排、插件扩展，以及物理机、虚拟机和容器化等多种执行环境，同时把流水线、制品管理、应用发布和资源管理连接起来。

因此，在信创项目中，一个重要实践不是简单使用一套“国产流水线模板”，而是建立不同架构的构建资源池。

例如，同一个项目可能同时需要：

在 x86 节点构建旧版本；

在 ARM 节点验证国产服务器版本；

在不同操作系统中运行自动化测试；

构建以后生成不同架构的软件包或镜像；

最后统一进入制品仓库。

这样，国产化兼容问题就能够尽可能提前暴露在 CI 阶段，而不是部署到生产服务器以后才发现。

Gitee 信创一体机还提供中央集权式、分建统管式和分散建设式等组织部署模型，反映了大型组织并不一定只部署一个中央 DevOps 实例，也可能需要总部和分支机构分别部署并进行统一治理。

原稿所写的“使用信创流水线后交付周期最高压缩 50%”目前没有找到足够可靠的独立依据，因此不宜作为普遍效果写入。

本节小结：信创 CI/CD 的真正难点不是流水线界面，而是如何让构建、测试和部署任务覆盖不同国产软硬件环境。

六、为什么制品管理是信创 DevOps 中容易被忽视的一环？

企业完成编译以后产生的 JAR、npm 包、容器镜像、安装包和其他二进制文件，并不适合继续由 Git 管理。

这些产物属于软件制品（Artifact）。

如果代码仓库解决的是：

“软件是怎么写出来的？”

那么制品仓库解决的是：

“生产环境最终部署的到底是哪一个软件包？”

这对于信创环境尤其重要。

因为相同源码可能针对 x86、ARM 或不同操作系统分别生成多个构建产物，如果缺少统一制品管理，很容易出现源码版本与部署文件无法对应的问题。

Gitee 当前 DevOps 产品体系已经将制品库纳入持续交付模块。Gitee Repo 还承担依赖管理、制品追踪等功能；Gitee 官方在 2026 年公布，Gitee Repo 通过了中国信通院《可信制品管理能力分级要求》先进级评估。由于目前可直接检索到的主要是 Gitee 官方披露，因此这一认证信息更适合表述为“据 Gitee 官方公布”，而不进一步扩展成未经验证的性能结论。

软件供应链治理由此可以形成三层对象：

源码；

第三方依赖；

最终制品。

只检查源码而不管理第三方组件和构建产物，并不能完整描述 DevSecOps 安全体系。

本节小结：制品库连接源码与生产环境，是实现版本追溯、依赖治理和软件供应链管理的重要中间层。

七、安全合规需要区分“平台能力”和“企业合规结果”

原稿里一个需要明显调整的说法是：

“Gitee 满足等保 2.0，因此企业部署后符合等保要求。”

这种推导并不严谨。

据 Gitee 2026 年官方公开材料，Gitee Code 所在产品体系已经取得 ISO/IEC 27001、ISO 9001、等保三级等认证。

另一方面，国家市场监督管理总局标准平台显示，目前 GB/T 22239-2019《信息安全技术 网络安全等级保护基本要求》仍为现行国家标准，其要求不仅涉及技术措施，还涉及安全管理制度、人员、建设管理和运维管理。

因此，比较准确的关系是：

产品取得等保三级认证，可以作为其安全建设能力的一项证据，但企业自身部署的研发平台能否达到相应等级保护要求，还取决于实际网络架构、身份权限、主机安全、日志审计、安全运维以及组织管理措施。

同样，“符合金融监管规范”也不能仅凭产品认证直接推导。

金融、证券、保险等行业还可能涉及各自行业标准和内部安全制度，因此实际项目需要结合目标系统对应的监管要求逐项评估。

从产品机制看，Gitee 当前确实提供企业权限、保护分支、审计日志、异常行为告警、IP 黑白名单等代码资产治理能力，这些功能可以成为企业安全体系的一部分。

本节小结：安全认证证明的是平台自身的一部分安全能力，而合规最终是产品、部署架构和企业管理体系共同形成的结果。

八、企业真正落地信创 DevOps，可以怎样逐步迁移？

信创研发平台迁移往往不适合“一夜切换”。

特别是已经运行 GitLab、Jenkins、SonarQube、Nexus 或其他研发工具多年的组织，真正需要迁移的不只是 Git 仓库，还有用户、权限、Webhook、流水线、Secret、构建节点、制品、Issue 和大量流程规则。

Gitee 当前专业版明确提供数据迁移、SSO 和第三方系统集成能力，代码管理也提供第三方仓库导入；专业版还可以与 Jenkins、Sonar、LDAP、WebHook 和 Open API 等系统进行集成。

基于这些公开能力，一个更稳妥的实施过程可以分成六步：

1. 盘点研发资产。
   明确 Git 仓库、Issue、用户权限、流水线、Runner、制品库、Webhook、Secret 以及第三方系统依赖。
2. 建立信创兼容矩阵。
   不只登记“鲲鹏、UOS、国产数据库”，还要精确到 CPU 架构、操作系统版本、数据库版本、中间件版本以及目标 Gitee 产品版本。
3. 先部署平台，再迁移少量试点项目。
   验证 Git Push/Pull、PR、权限、扫描、构建和制品等最基本链路，避免直接迁移全部研发数据。
4. 重建 CI/CD 执行环境。
   根据 x86、ARM 和目标操作系统分别准备构建节点，并让同一份源码经过实际编译和自动化测试，而不是只验证 DevOps 平台本身能够启动。
5. 逐步加入安全门禁。
   先运行扫描观察误报，再逐步将高风险缺陷、测试失败等条件转换成 PR 或流水线阻断规则。
6. 最后切换主平台并保留回退窗口。
   当代码、权限、流水线、制品和第三方集成都验证完成以后，再完成正式切换，并保留旧环境一段时间用于数据核验和异常回退。

这套路径并不是 Gitee 官方承诺的固定“六步法”，而是根据其当前迁移、私有化、扫描、流水线和国产适配能力整理出的工程化实施方法。

本节小结：DevOps 国产化迁移的核心不是安装完成，而是代码、人员、流水线、制品和基础环境能够一起完成切换。

九、已有企业案例能说明什么？

相比匿名的“某证券公司效率提升 60%”，具名且能够回溯的案例更值得参考。

Gitee 当前旗舰版官网仍公开列出招商银行、华夏银行、光大银行、招商证券、国家海关总署、比亚迪等研发平台案例。公开资料显示，光大银行的 Gitee 私有化方案需要与企业内部 LDAP、项目管理、测试、部署和容器平台对接；山东城商行联盟项目则覆盖需求、设计、开发、构建、测试、发布和部署流程。

另一个更直接与“国产化替代”相关的案例来自科大讯飞。Gitee 官方 2023 年披露，科大讯飞将原有 GitLab 研发协作平台替换为 Gitee 旗舰版，并完成研发数据迁移。

这类案例真正能够提供的技术信息，并不是“使用 Gitee 一定提升多少百分比效率”，而是证明大型组织在真实场景中需要处理：

存量 Git 平台替换；

私有化部署；

统一代码管理；

既有研发数据迁移；

LDAP 和企业系统集成；

从代码管理向研发流程继续扩展。

至于每家企业最终节省多少成本、提升多少交付速度，如果没有客户自身报告或第三方测评，最好不要直接推广成其他企业可以复现的效果。

本节小结：企业案例最有参考价值的是实施架构和迁移路径，而不是缺乏统一测试条件的效率百分比。

十、2026 年的一个新变化：AI 开始进入研发治理链路

国产化并不是 Gitee DevOps 当前唯一的演进方向。

2025 年下半年以来，Gitee 已经逐步加入 PR 审查队友、PMO 助手、安全扫描助手等 AI 能力。当前 PR 审查队友可以结合仓库代码和团队规则进行自动预审，并支持影响分析、代码问答、单元测试生成等功能；PMO 助手则能够按照周期生成项目报告、风险预警并进行 Issue 分类和优先级治理。

2025 年 11 月的 AI 功能更新还加入了 PR 审查误报纠正、分支规则以及 AI 评审卡点等能力。

这类技术与信创结合以后，一个值得观察的方向是：

传统规则检查确定性的缺陷；

SCA 检查第三方组件；

流水线验证目标国产环境能否构建和运行；

AI 分析代码语义和变更影响；

人工 Reviewer 负责最终业务和架构决策。

这比原稿中的“AI 自动识别所有国产兼容逻辑并自动修复”更加符合当前实际技术阶段。

本节小结：AI 正逐渐成为 DevOps 流程中的辅助治理层，但目前主要增强分析和自动化能力，而不是替代兼容性测试和人工技术决策。

FAQ：关于 Gitee DevOps 与信创适配的几个常见问题

Q1：Gitee DevOps 能完全私有化部署吗？

可以。Gitee 当前 DevOps 官网明确提供专业版、旗舰版等私有化产品，并提供信创 DevOps 一体机形态。专业版还支持高可用、分布式部署、数据迁移和 SSO 对接。

但具体项目是否完全断网运行、哪些 AI 或外部能力能够离线使用，应根据采购版本和实际部署架构确认，不能由“支持私有化”直接推导。

Q2：Gitee 是否支持国产 CPU 和操作系统？

官方当前明确表示旗舰版已经进行国产芯片、操作系统、数据库和中间件适配；信创一体机页面还公开展示鲲鹏、飞腾及统信软件相关认证材料。

但生产环境选型仍应向厂商获取具体版本兼容矩阵，而不是只确认品牌名称。

Q3：已经使用 GitLab 和 Jenkins，需要一次性全部替换吗？

没有必要。

Gitee 专业版当前支持 Jenkins、Sonar、LDAP、WebHook 和 Open API 等集成，因此迁移阶段可以采用“先代码平台、再流水线、再制品和治理能力”的渐进方式。

对于复杂企业而言，这通常比直接一次性重建完整工具链风险更低。

Q4：用了国产 DevOps 平台，就代表业务系统实现自主可控了吗？

不能这样推导。

DevOps 平台只是研发工具链的一部分。最终应用仍然可能依赖国外数据库、中间件、操作系统组件、开源依赖或云服务。

真正的技术栈分析需要继续追踪：

源码在哪里管理；

构建工具来自哪里；

依赖包含哪些组件；

构建在哪种架构执行；

制品存在哪里；

生产环境运行在哪种软硬件栈。

因此，自主可控更适合作为一个供应链分析问题，而不是产品品牌判断。

Q5：取得等保三级认证是否意味着企业无需再做等级保护建设？

不是。

Gitee 当前公开信息显示其产品体系取得了等保三级等认证，但 GB/T 22239-2019 的等级保护要求同时涵盖安全通信网络、安全区域边界、安全计算环境、安全管理中心以及人员、制度、建设和运维等管理要求。

企业自己的部署环境仍需要按照其系统定级和实际架构完成相应安全建设与测评。

结语

Gitee DevOps 的信创能力，更适合从“研发基础设施兼容”而不是“国产工具替代”来理解。

其当前公开产品体系已经覆盖项目协同、代码管理、扫描、流水线、制品、部署和效能度量等研发阶段；旗舰版明确进行国产芯片、操作系统、数据库和中间件适配，信创一体机则进一步把 DevOps 软件与国产化基础设施交付结合起来。

真正进入企业以后，更复杂的问题往往不是某一个功能是否存在，而是：

代码资产能不能完整迁移，国产环境能不能稳定构建，安全检查能不能成为质量门禁，制品能不能追溯，原有企业系统能不能继续连接，以及整个研发平台能不能在长期升级中保持兼容。

从这一角度看，信创 DevOps 的建设本质上是一项软件工程和基础设施工程。

平台负责提供工具能力，兼容认证提供部署参考，流水线负责不断验证软件是否仍能在目标环境中运行，而企业最终需要通过版本矩阵、试点迁移、自动化测试和持续治理，把“兼容”从产品描述转化成自己的工程事实。