doc: 网关协作开发交付规范

[wklken]

develop & self-testing

• 每个开发都要有一套完整的开发环境
• 修改helm charts之后, 必须dry-run确认, 并且在开发环境部署验证, 避免低级错误, 避免在后面的环节才发现问题返工
• 各自功能提 PR 前, 必须做好自测(可以构建dev镜像顶掉目标pod, 验证完整逻辑), 避免低级问题出现
• 重要: commit message必须符合规范, 清晰, 关联对应的issue; 会直接用于生成 release log
  • https://github.com/commitizen/cz-cli
  • https://github.com/streamich/git-cz

PR

• 需要填写 PR 对应的变更点, 以便让reviewer更好理解和处理, 方便后续追溯
• 涉及功能修改的 PR 必须包含单元测试
• PR 的所有检查及单元测试必须通过 (make test)
• PR 的代码风格检查必须通过 (make lint)

Code review

• 一个 PR 需要两个 reviewer approved
• 所有 conversation 必须 resolved
• conversation 点 resolve的时候, 必须填评论, 已修改可以填done, 不修改需要给到理由 => 不要直接点resolve (这样可能有的问题就沉掉了)

[wklken]

后续需要在自测+联调环境多花一些时间，基础的问题需要在前期能发现并解决。减少流入体验阶段+测试阶段的单据数量。【相对现在需要减少 1 轮体验+1 轮单测】

1. 为空规范 /抽屉规范（后续尽量避免， 自测阶段）
2. 设计稿还原度（样式/对齐/字体/颜色/等等，包括设计稿上指出的交互/限制， 自测阶段）
3. 基本功能的可用，是否合理 （按钮功能/表单增删改查校验/变更刷新/翻页/过滤条件等等，自测阶段+联调环境复测）
4. 后端需要验证保存数据是正确的，对应功能是生效的，所有相关接口是可用的且符合预期（自测阶段+联调环境复测）
5. 后端需要确保体验完整功能，主流程没问题，设计交互等符合预期（联调环境+体验）

---

下半年会改变一下目前的大版本策略，将需求拆细，固定时间出版本发布