V8程序

Appearance

源码管理规范 ​

源码管理规范

源代码管理办法 V1.0

一、总则 ​

为规范公司软件项目的源代码管理，保障源代码的安全性和可维护性，特制定此管理办法。本办法的依据是国家相关的软件工程标准与规范、公司软件项目管理规范等。

二、适用范围 ​

本办法适用于公司所有软件研发项目的源代码管理，包括所有部门和项目团队。所述源代码包括内部研发代码、外包代码、开源代码等。

三、术语和定义 ​

1. 角色相关术语与定义 ​

  • 代码管理员 (Code Admin): 负责代码仓库的用户及权限管理、代码备份等运维工作。
  • 研发人员 (R&D Engineer): 参与源代码编写，提交代码修改。
  • 代码审查人 (Code Reviewer): 对代码修改进行 review，确保代码质量。
  • 测试人员 (Tester): 基于代码进行软件测试，反馈 BUG。
  • 系统运维人员 (DevOps Engineer): 负责代码部署上线和持续集成。

2. 源代码相关术语与定义 ​

  • 源代码 (Source Code): 组成软件产品的所有可读代码和相关配置文件，是未编译的、可读的文本格式。
  • 版本控制系统 (Version Control System): 管理不同版本源代码变更的系统，如 Git、SVN 等。
  • 代码仓库 (Code Repository): 存储源代码的服务器，开发者可以在上面托管不同项目的源代码。
  • 提交 (Commit): 将源代码更新推送到代码仓库的过程。每次提交都会生成一个提交 ID。
  • 分支 (Branch): 源代码仓库中的一个代码线路，用于实现平行开发。
  • 主分支 (Main Branch): 源代码仓库的默认开发分支，通常保持最新的稳定代码。
  • 合并请求 (Merge Request): 在分支开发完成后，请求将代码合并到主分支的过程。需要审核后才能合并。
  • 代码审计 (Code Audit): 定期对源代码进行安全性和质量检查的过程。
  • 持续集成 (CI): 在代码提交后自动进行编译、测试等流程，反馈结果。
  • 文档 (Documentation): 软件相关的说明文档，如需求文档引用、设计文档、测试文档、测试报告。
  • 代码版本 (Code Version): 软件系统的一个固定状态，通常以版本号 identfiy。

四、源代码管理规范 ​

1. 源代码权属规定 ​

  • 公司员工在职期间所参与开发的所有源代码版权属于公司所有。
  • 第三方合作开发的源代码版权属于双方约定，需要签订版权协议。
  • 离职员工所开发的源代码必须交接给公司指定人员。

2. 源代码安全管理规定 ​

  • 源代码服务器需部署防火墙、入侵检测等安全控制措施。
  • 源代码访问权限进行分级和监控，采取最小授权原则。
  • 实施代码安全扫描，发现漏洞需立即修复。
  • 限制源代码在本地终端的存放时间，不得拷贝到非授权设备中。
  • 实施代码提交审查，防止非授权提交。

3. 源代码流转管理规定 ​

  • 代码提交、审查、合并需要按流程进行，不能自行修改主分支代码。
  • 重要的代码修改需要进行版本跟踪，备注修改原因。
  • 第三方代码引入需进行安全审查和版权确认。
  • 代码发布前需要进行严格的安全测试，版本需配合测试报告一并归档。

4. 源代码备份规定 ​

  • 需定期对源代码服务器进行备份，备份测试的数据与代码分离。
  • 重要代码修改后立即进行备份。
  • 配置自动化日常代码备份，人工进行周期全量备份。
  • 代码备份要有加密措施，保存期限不少于 5 年。
  • 建立异地容灾代码备份中心。

五、源代码开发规范 ​

1. 代码提交规范 ​

  • 提交代码前进行代码格式检查和测试，确保代码质量。
  • commit message 需描述修改内容和目的，格式统一。
  • 不得直接在主分支修改和提交代码。
  • 代码修改存储采用增量提交，每次一个独立可编译的变更。

2. 分支管理规范 ​

  • 从主分支创建开发分支，一个功能或任务对应一个分支。
  • 开发完成后合并回主分支，删除无用分支。
  • 主分支代码禁止修改，只允许从其他分支 merge。
  • 特定人员审批后才能向主分支合并代码。

3. 代码评审规范 ​

  • 代码在合并到主分支前必须经过评审。
  • 评审人数量至少 2 人，记录审查意见。
  • 评审内容包括代码逻辑、质量、安全性等方面。
  • 评审人不得直接修改代码，需要提交修改意见。

4. 注释规范 ​

  • 新增功能代码需要增加说明注释。
  • 复杂算法、业务逻辑需加注释说明。
  • 注释内容同步更新，禁止遗留无用注释。
  • 按语言规范要求编写注释格式。

5. 持续集成规范 ​

  • 提交代码后自动触发编译、测试、检查等流程。
  • 持续集成环境配置独立，与开发环境分离。
  • 测试覆盖率要求不低于 90%。
  • 出现错误时自动通知相关负责人。

六、代码版本号管理 ​

  • 对软件系统进行版本管理，版本号格式为 X.Y.Z(主版本号.次版本号.修订号)。
  • 主版本号表示整体架构和功能模块的重大变更。
  • 次版本号表示新增功能和优化改进。
  • 修订号表示问题修复和微小变更。
  • 版本号在代码仓库中进行统一管理，详细记录每次变更。
  • 版本发布时需要提交版本说明，包括功能变更、问题修复等信息。
  • 使用版本管理工具(如 Git)来跟踪版本库的各个变更。
  • 文档中的版本号必须与代码版本号保持一致。
  • 不同环境(开发/测试/生产)的代码版本有效控制。
  • 定期对版本库进行审计，避免版本混乱。
  • 对旧版本提供必要的维护或文档，方便后续引用。
  • 源代码版本号命名要规范，不能任意修改。
  • 源代码版本号由该源码仓库负责人按规定进行定义。
  • 源代码版本号并非与产品版本号一致。

七、代码仓库角色要求 ​

一个项目中必须明确规定相关角色责任人，以确保管理办法落实。

  • 仓库管理员: 授权审批仓库用户，进行权限分配，维护仓库系统功能。同时根据产品规划管理代码结构。
  • 主开发者: 在项目开发分支进行代码开发和维护。
  • 代码审查人: 对代码修改进行 Review，提供优化意见。
  • 测试人员: 基于分支代码进行测试，反馈问题。
  • 发布负责人: 将经测试的代码 build 并发布到生产环境。

八、源代码生命周期流程指导 ​

  • 仓库管理员根据产品需求，在代码仓库中创建项目，设置版本库，定义分支策略。
  • 主开发者在自己的开发分支上进行代码开发和单元测试。
  • 主开发者发起代码合并请求至当前版本发布分支。
  • 代码审查人根据审查规范，对主开发者的代码修改进行 review。
  • 主开发者根据审查反馈进行 bug 修复和代码优化。
  • 测试人员基于代码在开发环境进行功能测试和回归测试。
  • 主开发者根据测试反馈进行迭代开发和 bug 修复，直至达到上线标准。
  • 发布负责人根据部署规范，将代码部署到测试环境进行集成测试。
  • 根据测试报告结论，决定发布分支代码符合标准，进行上线。
  • 仓库管理员对已发布分支进行合入主分支的代码进行归档备份，标记 tag。
  • 仓库管理员维护版本文档和和代码版本的关联归并。

九、文档管理规范 ​

  • 研发过程中产生的文档需统一集中存档管理并与程序版本号关联。
  • 文档包括需求文档引用、程序设计文档、测试文档、测试报告。
  • 文档命名规范: 业务系统简称+文档类型+日期。
  • 文档修改后需及时更新版本号和修订记录。
  • 产品发布时需归档对应的文档版本作为唯一参考版本。
  • 文档访问权限按保密等级分级，非授权人员不得访问。
  • 文档定期进行审计，防止遗漏和无效文档的存在。
  • 对外提供文档前需审核确认内容的正确性。

十、责任追究 ​

  • 研发人员违反代码管理规范，根据情节轻重进行记过、降级、辞退。
  • 管理人员未能有效监督，进行问责并记录不良记录。
  • 外部团队泄密造成损失的，要求赔偿及中止合作。
  • 严重失职行为涉嫌犯罪的，移交司法机关处理。
  • 每季度进行规范落实检查，作为考评依据。