极狐GitLab嵌入式开发场景解决方案

3.1 高可用部署与灾备

3.2 组织管理

3.3 分支策略

3.4 分支保护

3.5 推送规则

3.6 代码评审

3.7 数据保护

3.8 其他相关

本文来自

武让极狐GitLab 高级解决方案架构师

💡 前两篇文章，作者介绍了嵌入式开发场景之

代码管理特点与诉求，代码管理工具与方式之 SVN 与 Git
嵌入式开发场景的代码管理分仓、权限与依赖问题，以及基于 Git 的多仓管理

👆戳链接即可回顾前情。

本文进一步介绍极狐GitLab 针对嵌入式开发的解决方案。Enjoy～

极狐GitLab 嵌入式开发场景解决方案

围绕企业对于嵌入式开发场景的诉求，极狐GitLab 提供了一整套解决方案，可以较好解决嵌入式开发场景下的种种问题，重点包括以下几部分内容。

3.1 高可用部署与灾备

企业进行代码统一管理的前提是代码管理系统具备高可用、高性能以及容灾等特性，才能支撑企业安全可靠的管理代码数据资产。

极狐GitLab 专业版提供高可用部署方案，是松耦合分布式架构，各组件均为多副本部署，各组件均可实现横向扩展。

极狐GitLab 高可用架构通过横向扩展同时实现了高性能，针对从 1k 到 50k 用户数场景提供了不同的参考架构，满足不同用户规模的企业。

极狐GitLab 同时提供 GEO 主从架构部署方案，该方案为一主多从架构，主从节点配置不必完全一致，主节点提供读写服务，从节点提供只读服务，数据在主从节点之间实时同步，可实现：

通过访问就近节点加速；
负载分担；
准实时备份；
灾难恢复。

当主节点出现故障后可在几分钟内将从节点切换为主节点，恢复服务。

极狐GitLab GEO 在实现准高可用的同时，极大降低基础设施资源成本、部署和运维成本。

3.2 组织管理

极狐GitLab 通过群组、子群组嵌套关系实现对企业复杂组织关系的映射，嵌套最多支持 20 层，可以有效管理企业中的部门、组织、虚拟组织、项目。

代码库隶属于群组或子群组，可在任意群组、子群组对仓库和人员权限进行管理。

对于需要总览整个群组的管理人员，可以将其在父群组上分配权限，该用户的权限将被继承到所有子群组和代码库中；
对于需要查看部分内容的项目经理，可以将其在某个子群组上分配权限，该用户只可看到子群组下所有子子群组和代码库的数据；
对于只专注于具体功能模块的开发人员，只需要将其在具体的代码库上分配权限即可，这样就实现了在分仓模式下的授权管理。

3.3 分支策略

前文提到，分支管理是 Git 的优势，分支策略也是体现 Git 高效协同的重要价值，此外分支策略直接决定了研发流程的标准化。

从事嵌入式开发的企业进行 DevOps 转型，首先要考虑的就是分支策略怎么建立。以下是常见的几种分支模型，可供参考：

从极狐GitLab 自身实践的角度出发，我更倾向两种分支策略：

上图是极狐GitLab 自己的分支策略，本身是属于版本分支 GitLab Flow，适合多人协同的大、中型项目。相较于Git Flow 裁剪了一些不必要的分支，降低复杂度；
下图是对于小型项目推荐的极简分支策略，本身是属于 GitHub Flow，适合单人或者较少人员协同的小型项目。

需要注意的是，没有所谓的最佳分支策略，因为不同企业的研发流程不一样，即便是同一家企业的不同团队或者同一个团队在不同时期的研发流程也是不一样的，这时候就需要基于这些常见的分支策略总结和提炼一套属于自己的分支模型，并且对它持续进行检验和迭代。比如对于小型嵌入式项目，如果存在对不同的芯片或用户有定制版本，那么更建议基于 GitHub Flow，加入 Release 分支来管理不同的交付版本。

3.4 分支保护

当分支策略制定完成，如何保证开发人员遵循这套流程？那一定是需要工具层面有约束手段。

极狐GitLab 提供分支保护功能，可以限制开发人员直接向主分支提交代码，必须通过向 feature 分支或 dev 分支提交代码，再通过 Merge Requests 的方式合并到主分支，可以降低代码冲突，提高协同效率，同时也为开发团队践行代码评审提供了工具侧的落地支撑。

此外极狐GitLab 专业版实现了更加精细化的分支保护管理，可以对于指定的用户设置推送和合并权限，以此保证分支代码的可审核和可追溯性，免费版只能较粗粒度的指定某一类用户角色，如 Developer、Maintainer。

3.5 推送规则

代码规范也是 DevOps 转型非常关注的内容，以往粗放式的代码提交方式容易导致代码提交记录极度混乱、不可识别，比如大量 1111、test1 之类的提交记录，不仅让协同人员无法接手、难以理解，甚至提交人自己也无法基于这些记录进行拉取或者回滚操作。

极狐GitLab 专业版提供的推送规则功能可以很好的解决这个问题，它可以实现：

验证提交人是否是极狐GitLab 用户；
自定义正则表达式，验证代码提交记录是否符合一定的规范；
自定义正则表达式，验证分支名称是否符合一定的规范；
自定义正则表达式，验证提交文件中是否有不符合规范的文件，比如 .zip、.tar 文件；
验证提交的文件是否超过一定的大小。

推送规则验证不通过，则代码无法被推送到极狐GitLab 代码库中，从而确保研发人员严格按照规范进行代码提交。

规范代码提交信息可配合 Commitizen 工具，它可以按照一些行业内通用的提交规范引导开发人员填写提交信息；也可以配合 .gitignore 文件过滤一些不需要上传的文件或文件类型。它们都是在客户端发挥检查作用，本身不具备约束性质，开发人员可用可不用，而推送规则是在服务端进行验证，确保最终合规。

所以可以说 Commitizen、.gitignore 是源头检查，推送规则是尽头把关。两者可配合，但前者不可替代后者。

3.6 代码评审

由于嵌入式开发的周期相对较长，交付频率相对较慢，交付物多是固件，不具备互联网纯软件、高速迭代、灵活升级的特性，所以处理问题的成本也比较高，这也使得近些年从事嵌入式开发的企业对软件质量的要求逐渐提高，而提高软件质量最常用的方式就是进行代码评审。

极狐GitLab 专业版提供了完善的代码评审机制，其中主要包括：

支持强制代码评审，评审不通过不允许合并代码；
支持自定义代码评审规则，针对不同分支设置不同评审人，以及最小核准人数；
支持多重审批规则；
支持当单元测试覆盖率降低时触发代码评审；
支持阻止代码提交人、合并请求发起人进行评审；
支持设置 Code Ower（代码负责人）为审批人。

其中 Code Owner 可以为代码库的不同目录、不同文件、不同文件后缀设置代码评审人，比如：

这就实现了对 Git 代码库的目录、文件进行写入控制，也解答了上文中遗留的问题。

3.7 数据保护

上文也提到了数据保护，代码防泄漏的相关问题，具体落实到系统层面，极狐GitLab 可以从事前、事中、事后三个方面提供支撑。其中最重要的是对极狐GitLab 的操作行为进行记录和分析，实现审计功能。

极狐GitLab专业版支持对创建仓库、修改密码、权限变更等系统事件进行审计，也支持对代码推拉事件进行审计，并可以事件流的方式传递给第三方日志系统，以便对数据进行分析和展示，也可以制定一些规则并触发告警或通知。

此外，在与第三方 DLP 工具对接的过程中，我们发现有些客户的 DLP 工具只能对 Git 客户端或 IDE 进行加密，而 GitLab 本身还可以通过在网页上直接打包下载的方式获取源码，这给客户的数据保护工作造成一些麻烦。所以极狐GitLab 为这个本土化需求增加了一项功能，可以在网页上禁用源代码下载，以便更好的解决数据保护问题。

3.8 其他相关

除了以上在源代码管理方面的优势外，极狐GitLab 还提供了一些其他的附加功能，比如：

在工具方面，极狐GitLab 提供了 IDE 插件，可以更方便对极狐GitLab 中的项目、代码、流水线进行管理；提供了 WebIDE，可以在线对代码进行查看、对比、编辑操作。

在项目管理方面，极狐GitLab 自身提供轻量的偏敏捷的项目管理功能，且可以和主流的项目管理工具如 Jira、禅道、PingCode 以及和传统制造行业常用的 PLM 系统 Windchill 进行集成和打通，实现在需求管理系统中查看该需求任务关联了哪些极狐GitLab 的代码提交和合并请求，实现项目到开发的流程关联与追溯。

流水线是 DevOps 中的重要组成部分，也是研发效率提升的根本，极狐GitLab 提供了开箱即用的 CI/CD 功能，相较于Jenkins，极狐GitLab CI 依靠其一体化、轻量化、声明式、开箱即用的特性，在开发者群体中的使用率越来越高，在国内企业中仅次于 Jenkins 排在第二位。极狐GitLab 也为从事嵌入式开发的企业做完源代码统一管理后，进行更进一步的 DevOps 转型提供支撑和帮助。

最后，随着物联网、人工智能等技术的不断发展，嵌入式系统的应用场景将会更加广泛，这将会催生更多的 DevOps 应用场景，也会进一步推动 DevOps 在嵌入式开发场景中的落地，期待那一天早点来到。

参考：