开发流程

查阅这些主题以获取有关为极狐GitLab 做贡献的开发流程信息。

流程#

必读：

• 适配现有组件和引入新组件的指南
• 代码审查指南，用于审查代码和被审查代码
• 数据库审查指南，用于审查数据库相关变更和复杂 SQL 查询，以及被审查
• 安全编码指南
• 极狐GitLab 项目的流水线
• 避免必需的停止

补充阅读：

• 为极狐GitLab 做贡献
• 开发者安全流程
• 开发者补丁发布流程
• 实现企业版功能的指南
• 向极狐GitLab 添加新服务组件
• 变更日志指南
• 依赖项
• Danger bot
• 在 JihuLab.com 上请求访问 ChatOps（适用于极狐GitLab 团队成员）

开发指南评审#

对于开发指南的变更，请请求经验丰富的极狐GitLab 团队成员进行审查和批准。

例如，如果你正在记录一个仅供特定群组使用的新的内部 API，请请求该群组的一名成员进行工程审查。

小的修复，如拼写错误，可以由任何至少具有维护者角色的用户合并。

更广泛的变更#

有些变更会影响多个群组。例如：

• 对 代码审查指南 的变更。
• 对 提交消息指南 的变更。
• 对 极狐GitLab 开发中的功能标志 指南的变更。
• 对 功能标志文档指南 的变更。

在这些情况下，请使用以下工作流程：

1. 请求你团队的一名成员进行同行评审。

2. 请求负责相关领域的工程经理 (EM) 或高级工程师进行审查和批准：

   • 前端
   • 后端
   • 数据库
   • 用户体验 (UX)
   • 安全
   • 质量
     • 工程生产力
   • 基础设施

   对于由负责其领域的 EM 或高级工程师编写的 MR，你可以跳过此步骤。

   如果有多个受影响的群组，你可能需要每个受影响领域的 EM/高级工程师级别的批准。

3. 完成审查后，请与 MR 的 EM/高级工程师作者/批准者协商。

   如果这是跨多个领域的重大变更，请请求开发副总裁进行最终审查和批准，他是开发指南的 DRI。

任何维护者都可以合并 MR。

技术写作评审#

如果你希望技术写作人员进行审查，请在 #docs Slack 频道中发布消息。 但是，技术写作人员不需要审查内容，并且除 MR 作者之外的任何维护者都可以合并。

评审者价值观#

作为审查者或被审查者，请确保熟悉我们在极狐GitLab 努力追求的 评审者价值观。

此外，任何文档内容都应遵循 文档风格指南。

语言特定指南#

Go 指南#

• Go 指南

Shell 脚本指南#

• Shell 脚本标准和风格指南

清晰的书面沟通#

在议题或合并请求或任何其他沟通方式中撰写任何评论时，在使用诸如 "MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、"SHALL NOT"、"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"MAY" 和 "OPTIONAL" 等术语时，请遵循 IETF 标准。

这确保了来自不同文化的不同团队成员对所使用术语有清晰的理解。