团队代码协作规范 及 产品发布流程

团队代码协作规范 - 基于git flow工作流

git-flow

分支解释：

• master :不允许开发者对代码进行修改和提交。该分支上的代码随时可以部署到生产环境
• develop:是开发过程中代码中心分支。不允许开发者直接进行修改和提交（只允许MR(PR)，以下MR 均指 Merge Request）
• Release:临时分支:上线的准备工作和预演环境的bug。绝不能包含需求变更或功能变更等重大修正。这一阶段的提交数应该限制到最低
• Hotfix:临时分支,修复紧急bug的分支；紧急bug定义：无法等到下个版本的bug
• Feature:开发分支，已完成的feature 需要在适当时间删除；需要其他开发者对对此次MR进行code review，在通过审核后Accept Merge Request 发布到dev

优势：

• 通过不同分支间的交互规划了一套软件开发、集成、部署的工作流
• 基于不同分支完成不同环境的发布
• CodeReview，开发者的代码，可以在MR 到dev branch 过程进行peer review，再MR 到release branch 时做 lead review
• 可直接集成各种CI tools，进行持续发布；不过一般情况是，测试环境采取 auto deploy，预演和生产环境 manual deploy

实施要求：

• 整个团队的纪律性要求很高
• 要求团队成员熟练掌握git 指令、gitflow原理流程
• 有git-flow 扩展指令集，推荐使用sourceTree 做为git-flow gui 工具

注意事项：

• 两条主分支：develop & master，贯彻整个流程始终
• feature 分支，粒度划分要细，建议不超过一周，杜绝出现long-lived-branches;多人协作时；建议每日从dev pull 一次代码；建议发起mr前均需要pull 一次代码，修复冲突后才能mr到dev 分支
• develop和master分支，需要设置为protected branch，杜绝直接commit和merge代码
• release分支，只做bug 修复，bug修复完后，发布上线，同时要将修复的代码 mr 到dev
• hotfix分支，线上出现bug需要进行紧急修复，可以从master 拉一个hotfix分支，修复后及时mr 到master 和 dev 分支；线上出现重大bug，或者bug一时难以修复，需要基于上一个tag进行回滚操作。

产品发布流程 - 基于git flow工作流

git-flow

(1)(2)(3)步骤说明

(1)上测试环境，feature 通过merge request 到dev：

• 在 MR 前，需要从dev 作 pull 操作
• 在 MR 前，需要功能自测 ，核心服务通过unit test
• MR 过程中需要assign to peer developer 作 Peer review，双方均需对此次mr 负有责任；Code Reviewer之Peer Review，审查代码逻辑错误，建议更好的实现
• MR 完成后，基于dev 分支 发布到测试环境；（可以手动，也可以自动）
• 发布到测试环境后，由QA&UI 负责校验 任务是否达到DoD标准，未能通过检验，返回给研发进行修改

(2)上预发布环境，从dev 发起 merge request 到release：

• 在MR前，需要当前sprint 内所有task 均达到DoD标准，所有bug fixed
• 在MR前，需要QA/Tester通过对测试环境的功能测试、性能测试、兼容性测试
• 在MR前，需要UI Designer通过对产品进行还原度确认
• 在MR前，需要由Team Leader/架构师 作 Lead Review，对代码架构进行审查，保证代码的重构与复用
• 基于release 分支发布到预发布环境；release 分支的改动要在上线前MR回dev和master
• 发布release，意味着此次sprint 的研发结束，后续的研发 就要算作next release 版本

(3)上生产环境，从release 发起merge request 到 master：

• 在MR前，需要通过QA/Tester通过All Test Case的回归测试
• 在MR前，需要需求方／PO confirmed，可以通过sprint review meeting 达成
• 在MR后，需要基于master分支 建立tag进行备份
• 发布上线后，做冒烟测试
• 线上出现重大异常或一时无法修复的异常，需要即可基于上一个的tag进行回滚，修复完成后再重新上线

注意情况：

• (1)(2)(3)在服务器到位情况下，需要优先配置好jenkins 各个环境的deploy item 配置
• 上线频率需要控制好，一般约定周二、周四，一旦存在问题可以第二日进行修复

备注

以上流程，适用 多人协作、持续迭代、产品各个环节质量和可用性要求高的情况；对于简单项目／对产品可用性要求不高的项目可以在流程上做适当精简分支；具体操作：

1. 精简掉release分支，变更为基于dev 发布上预演；
2. 精简掉hotfix分支，变更为基于feature 修复，dev 上做验证，再上线
3. 上线过程不接受任何成员提交的新需求的MR，只接受bug 修复的代码MR