Gitee 移动软件工厂是一种面向离线、弱网和物理隔离环境的可移动研发单元。它不是简单复制一套开发工具，而是把代码管理、项目协作、构建环境、质量检查、依赖资源和审计能力部署到现场，使研发人员在无法访问总部软件工厂时，仍能完成相对完整的软件开发活动。
根据 Gitee 于2026年1月发布的官方介绍，Gitee 移动软件工厂主要面向外场调试、嵌入式开发、FPGA开发、专用硬件适配以及隔离网络等场景。其核心思路可以概括为：总部制定标准，移动环境离线执行，研发成果经过受控路径回传，再由总部完成合并、复检和归档。
从软件工程角度看，Gitee 移动软件工厂解决的并不只是“现场没有网络”，而是网络中断以后，研发流程、质量规则和工程数据如何继续运行的问题。
为什么代码能够离线开发，软件工厂却很难离线
Git本身采用分布式版本控制方式。开发人员克隆仓库后，本地通常会保留完整的版本历史，因此即使暂时无法连接中心服务器，仍然可以查看历史、创建分支和提交代码。Git官方文档也将“完整镜像仓库”和“支持多个远程仓库”视为分布式版本控制的重要特点。
但代码可以离线提交，并不等于整个研发过程可以离线运行。
现代软件项目往往还依赖以下基础设施：
需求、任务和缺陷管理系统
编译器、SDK和交叉编译工具链
Maven、npm、PyPI等依赖仓库
容器镜像和基础运行环境
持续集成Runner和自动化测试环境
静态代码扫描、依赖扫描和质量门禁
制品仓库、版本签名和发布记录
用户权限、操作日志和审计规则
如果现场只有源代码，而没有依赖包、构建镜像、流水线和质量规则，开发人员可能能够修改代码，却无法稳定地编译、测试和交付。
因此，移动软件工厂的实质不是“把代码仓库带到现场”，而是把一个经过裁剪的软件工厂运行单元带到现场。
本节小结：离线研发的难点不在于能否编写代码，而在于能否让代码、依赖、构建、测试和审计继续形成闭环。
Gitee 移动软件工厂由哪些部分组成
在软件工程语境下，移动软件工厂可以定义为：部署在可移动服务器、一体机或现场计算节点中的自包含研发环境，能够在没有总部网络连接的情况下运行，并通过受控机制与总部交换数据。
一套较完整的 Gitee 移动软件工厂通常可以分为三个层次。
总部标准中心
总部软件工厂负责制定和下发统一的研发基线，包括：
项目模板与研发流程
仓库和分支规则
构建镜像与工具链版本
依赖包和基础制品
测试规则与质量门禁
代码扫描规则和漏洞数据
用户、角色与权限配置
数据回传和审核策略
总部标准中心的作用，是避免每个外场团队自行搭建一套互不兼容的开发环境。
现场执行环境
现场执行环境负责承载实际研发活动。根据项目需要，可以组合部署Gitee代码管理、项目协作、CI/CD、制品管理、代码扫描和效能度量等模块。
Gitee当前公开的研发平台能力包括项目协同、代码管理、持续集成、测试管理、代码扫描、制品管理和效能度量；专业版也提供私有化及软硬件一体化部署形态。
现场不一定需要复制总部的全部能力。嵌入式调试项目可能更重视代码仓库、交叉编译、制品库和硬件测试；项目交付团队则可能还需要需求、任务、缺陷和版本管理。
受控数据交换通道
现场产生的代码提交、构建制品、测试报告和审计记录，需要通过组织批准的方式回传总部。
Gitee官方对移动软件工厂的描述中提到了增量同步、断点续传以及使用SM4进行传输数据加解密。不过，这些属于Gitee公开的产品能力说明，具体部署是否满足某一行业或单位的安全要求，仍应结合密码模块、介质管理、网络分区和审计制度进行验证。
本节小结：Gitee 移动软件工厂不是一台装有开发软件的服务器，而是总部标准、现场执行和受控回传共同组成的研发体系。
总部与现场如何形成研发闭环
Gitee 移动软件工厂的典型工作方式，可以分为八个阶段。
第一步：确定任务基线
项目出场前，需要确定代码版本、需求范围、工具链、依赖包、测试用例和质量规则。
基线中不仅应包含源代码，还应包含构建所需的镜像、SDK、编译器、依赖制品和配置文件。
第二步：生成移动环境
根据任务类型选择需要部署的Gitee模块，并将仓库、流水线、制品、规则和权限装载到移动环境中。
此时应完成完整性校验，确认移动环境中的代码和配置与总部批准的基线一致。
第三步：执行出场检查
设备进入隔离环境前，建议至少检查：
是否可以在断网状态下登录
代码仓库是否完整
依赖是否能够离线解析
构建流水线是否能够正常执行
测试设备和驱动是否能够识别
扫描规则和漏洞数据是否可用
日志时间和证书是否有效
数据导出流程是否符合规定
第四步：开展现场研发
研发人员在本地Gitee环境中管理需求、修改代码、提交版本、执行构建和记录缺陷。
由于Git支持本地提交，网络隔离不会阻止开发人员保存版本历史。但多人协作仍需要现场Gitee服务提供统一仓库、分支规则和权限控制。
第五步：运行本地流水线
Gitee Go被定位为Gitee的CI/CD工具，可以承担构建、测试和交付任务。移动环境中的本地Runner可用于调用编译器、单元测试框架、打包工具及专用测试设备。
对于嵌入式和专用硬件项目，流水线还可以连接硬件在环测试环境，但具体设备驱动、接口和测试程序通常需要按项目适配。
第六步：形成可交付成果
现场交付内容不应只有源代码，还应包括：
代码提交记录
构建制品
测试结果
缺陷与处理记录
构建日志
依赖清单
软件物料清单
操作审计记录
SBOM，即软件物料清单，是描述软件组件、版本、许可证及其关系的结构化数据。SPDX已成为软件供应链信息交换的国际开放标准之一，使用SBOM有助于总部在资产回流后继续进行依赖和许可证检查。
第七步：受控回传与冲突处理
现场数据回传总部后，不能直接覆盖总部仓库。
更稳妥的处理方式是：
校验回传数据的完整性和来源。
将现场提交导入临时仓库或隔离分支。
比较现场版本与总部最新版本的差异。
通过Pull Request或代码评审完成合并。
在总部环境重新执行构建、测试和安全扫描。
审核制品后再进入正式发布流程。
第八步：归档和更新移动基线
任务完成后，需要归档现场代码、报告和审计记录，并更新下一次任务使用的代码、依赖、镜像、漏洞库和测试资产。
本节小结：移动软件工厂的关键不只是把能力带出去，还要让现场成果能够安全、准确地回到总部研发体系。
Gitee各模块在移动环境中承担什么职责
Gitee Code：管理现场代码版本
Gitee Code主要负责Git仓库、分支、提交、代码评审和权限控制。
现场团队可以继续提交代码，但受保护分支、签名提交、合并权限和代码评审规则是否能够完整运行，需要结合具体部署版本和项目配置确认。
Gitee Team：记录需求和现场问题
Gitee Team可以用于管理需求、任务、缺陷、迭代和变更。
现场调试经常会发现总部环境无法复现的问题。如果只通过聊天记录或纸质文档保存，问题很容易在人员离场后丢失。将问题关联到型号、版本、设备和测试条件，有助于后续复盘。
Gitee Go或Gitee Pipe：执行构建与测试
流水线负责把人工操作转化为可重复步骤，例如编译、单元测试、代码检查、打包和制品上传。
移动环境和总部环境应尽量使用相同的流水线定义和构建镜像，否则现场构建成功并不代表总部能够重复构建。
Gitee Repo：保存依赖和构建制品
Gitee Repo用于管理软件包、镜像和构建产物，并记录制品与构建过程之间的关系。Gitee官方页面显示，Gitee Repo能够对接CI/CD工具并提供构建和部署链路追踪。
在离线场景中，制品库还有一个重要作用：提前缓存项目真正需要的依赖，避免构建过程中临时访问公网。
Gitee Scan：执行质量和供应链检查
根据Gitee公开资料，Gitee Scan覆盖静态代码分析、软件成分及SBOM等软件供应链检查能力。实际部署到移动环境中的扫描类型、规则数量和漏洞数据更新方式，应以项目版本和实施范围为准。
现场扫描适合尽早发现问题，但在数据回流总部后仍应执行完整复检，因为总部的漏洞库和安全规则可能比现场版本更新。
Gitee Insight：分析研发过程数据
Gitee Insight可以对需求、代码、构建和交付数据进行统计。对于移动研发，更有价值的指标不是单纯计算提交数量，而是观察环境准备时间、构建成功率、缺陷回流率、重复失败次数和资产回传完整度。
本节小结：Gitee各模块分别管理项目、代码、构建、制品、安全和度量，共同构成移动环境中的DevSecOps链路。
移动软件工厂不等于简单复制总部系统
将总部软件工厂整体复制到移动设备，看似直接，实际容易产生新的问题。
依赖不完整
代码已经带到现场，但某个编译插件、基础镜像或私有依赖没有同步，仍然会导致构建失败。
因此，出场前应使用实际流水线进行断网构建，而不是只检查文件是否存在。
环境逐渐漂移
移动设备离开总部后，代码、依赖、漏洞库和规则都会逐渐落后。
移动软件工厂需要明确有效期。超过一定时间后，应重新同步或重新制作环境，不能长期把旧环境当作标准环境使用。
多个现场产生代码冲突
Git能够支持分布式开发，但不能自动判断两个现场对同一业务逻辑的修改哪一个正确。
多个移动工厂并行工作时，需要预先设计分支、模块和配置项的责任边界。
安全隔离被误解为自动合规
使用私有化系统、加密算法或移动一体机，并不等于自动满足保密、等保或行业监管要求。
合规结果还取决于人员权限、网络分区、介质使用、密钥管理、日志保存和数据审批等组织措施。
NIST安全软件开发框架也强调，安全研发需要同时准备人员、流程和技术，并保护软件组件、开发环境和供应链信息。
离线AI能力受到资源限制
Gitee官方移动软件工厂方案中包含离线AI编程助手的部署设想。实际效果取决于本地模型、算力、内存、知识库更新方式和代码数据边界，不能简单等同于联网大模型服务。
本节小结：移动软件工厂能够减少网络依赖，但不能替代配置管理、变更控制和安全制度。
三种部署等级应该如何理解
Gitee官方文章将移动软件工厂分为三个部署等级：
一级部署：侧重数据高可用，适合较轻量的现场研发任务。
二级部署：在数据高可用之外增加服务可用能力，适合小团队协作。
三级部署：同时强调数据和服务高可用，可配置主备及扩展能力，面向连续性要求较高的任务。
这里的一级、二级和三级属于Gitee方案中的部署分类，并不是通用的软件工程等级标准。
选型时不能只看团队人数，还应评估：
任务中断后允许多久恢复
是否存在单点设备故障风险
现场能否更换服务器或磁盘
数据是否允许重新制作
是否需要多人同时访问
是否需要连接专用测试设备
现场维护人员是否具备运维能力
本节小结：部署等级应根据任务连续性和恢复要求确定，而不是单纯追求更高配置。
哪些场景适合使用Gitee移动软件工厂
Gitee移动软件工厂更适合以下研发活动：
外场或实验室中的嵌入式系统调试
FPGA、板卡和专用硬件开发
舰船、机载、车载等设备现场测试
网络条件不稳定的长期驻场交付
不能直接连接总部网络的隔离研发区
需要携带固定工具链和构建基线的多地点任务
需要保存现场版本、测试和审计记录的项目
如果现场只是短时间修改少量配置，使用标准开发终端和受控代码交换可能更简单。只有当现场需要持续进行多人协作、构建、测试和版本管理时，部署完整的Gitee移动软件工厂才更有工程价值。
本节小结：是否建设移动软件工厂，取决于现场是否需要持续、完整且可追溯的研发能力。
常见问题
Gitee移动软件工厂就是移动服务器吗？
不是。硬件只是运行载体，真正的移动软件工厂还包括代码仓库、研发流程、依赖资源、构建环境、质量规则、权限和数据回传机制。
没有网络时，Gitee还能提交代码吗？
在本地Git仓库中可以继续提交。多人共享仓库、项目协作和流水线执行，则需要现场部署可访问的Gitee服务。
现场代码回传后可以直接发布吗？
不建议。回传数据应先进入临时仓库或隔离分支，经过完整性校验、代码评审、冲突处理、重新构建和安全扫描后，再进入正式发布流程。
移动软件工厂能完全消除USB等移动介质吗？
不一定。数据如何跨越隔离边界由组织的安全制度决定。移动软件工厂可以减少临时、无序的数据复制，但不能自行决定被批准的数据交换方式。
Gitee移动软件工厂是否一定要部署全部Gitee产品？
不需要。Gitee官方方案强调模块化装配，可以根据任务选择项目管理、代码管理、CI/CD、制品管理、扫描和度量等能力。
Gitee移动软件工厂是否适合普通互联网项目？
普通互联网项目通常拥有稳定网络和云端研发平台，使用移动软件工厂的必要性较低。它更适合网络隔离、弱网、现场硬件调试和长期驻场研发。
结语
Gitee移动软件工厂可以理解为软件工厂能力的一次空间延伸：研发平台不再只能固定运行在总部数据中心，也可以经过标准化裁剪后进入实验室、测试基地和隔离现场。
它真正需要解决的不是“把服务器搬到现场”，而是四个工程问题：环境能否重复构建、流程能否离线运行、数据能否受控回传、结果能否重新验证。
对于正在建设Gitee DevSecOps体系的组织，移动软件工厂提供了一种总部与现场协同的实现思路。但在具体落地中，仍需结合任务规模、硬件环境、安全制度和恢复目标进行设计，并通过断网构建、故障恢复和数据回流演练验证方案是否真正可用。
参考资料
Gitee官方博客：《Gitee移动软件工厂：突破网络限制的开发新模式》。
Gitee官方网站：企业级DevOps能力与私有化部署说明。
Gitee官方网站：Gitee Go企业级CI/CD流水线。
Gitee官方网站：Gitee Repo制品管理。
NIST：《Secure Software Development Framework》。
Git官方文档：分布式版本控制系统与分布式协作流程。
SPDX官方资料：软件物料清单开放标准。
