打造高效小团队 - 团队代码提交流程 && 规范

代码提交规范 && 升级调整

本系列想跟你们分享一下我近一年的管理经验，分享一下咱们团队的一年走来的优化之路「非技术」，让你们少踩坑，以及如何协做，管理者容易遇到的问题，以及技术上，工做上，如何与同事沟通、跨部门如何沟通有效率、如何分组、站会有没有用？ 等等，一年到头，想和你们交流一下经验。

背景

项目早期

无论前端仍是后端，项目早期，咱们是有 master 被保护分支，以及 dev 测试分支的，咱们的提交流程是：全部人往 dev 合并代码，进行测试封版，测试经过直接把 dev 合并到 master 进行升级。随之而来发现了问题：

项目中期

咱们不能保证 dev 上的代码所有测试经过，由于没有充足的测试时间，并且不断有新的提交涌入，dev 直接合并到 master 确定是不够稳妥的，这样的 dev 没有任何意义，随着研发任务强度愈来愈高，索性废弃了 dev ，直接合并到 master ， master 分支作持续集成到测试环境，每周二升级生产环境。每周三打 TAG，期间有迭代直接提交，直到下周二继续升级，若是很是紧急，那就基于 git tag 基础上修改，提交，升级生产。

反思

好景不长，随着研发任务的进一步提高，问题接踵而来，新业务测试不熟悉，测试时间长，每周二11点还没测试完毕，甚至每周二晚9点多才发现某某功能需求有问题，还会有其余小组影响另外小组的进度（关于小组之后单独讲）。这让研发叫苦连天。每周二的 升级日 变成了 “加班日” ，虽然每周只有一天，且次日能够晚点来上班，可是连续两周下来，仍是有个别同事出现了严重的负面情绪，怕影响其余人，因此须要迅速解决这个问题。大刀阔斧的调整流程！

参考资料

• 闲鱼技术
• 流程规范

上文资料请你们简单看一看,咱们通过讨论作了调整，可是基本原理不变。

调整

研发 随写随提，测试 随提随测，运维 随测随更。随时测试，随时更新，随时升级生产环境。

协商一个时间点，好比天天 19:30，过了 19:30 的需求、bug，明天在调整，尽早回家休息。

研发职责

研发负责人仍是像之前同样，多创建一个 dev 分支，用于测试，这里对 dev 的功能作下说明:

dev 分支

dev 分支就是测试环境，咱们把 CI 从 master 换成 dev

这个分支，不须要有权限控制，研发根据 禅道 或者 card 上的任务，从 master check 出一份分支

以 禅道 bug http://xx.104.96.233:60888/zentao/bug-view-11568.html 为例

• 咱们为分支命名为： fix-bug-11568

• 修复 BUG

• commit 代码写好 msg:fix xxx ， merge 到 dev 「fix-bug-11568 分支此时不要删除」

• 通知相关人士进行测试

• 测试失败「打回从新提交」，测试成功点击「关闭」通知研发能够了。

• 研发发起 PR 从「 fix-bug-11568 分支 （注意！不是 dev）」到 Master 后 「 fix-bug-11568 」由管理员合并并删除

• 此时 Master 随时能够升级到生产。

这样会比较麻烦，因而参考 闲鱼技术 咱们也自研了一套流程工具，具体下次专门出篇文章讲讲。

研发禁止的

• 禁止从 dev 分支 check 代码，由于你要保证合并到 master 的只有你本身的，没有其余人没测试的，若是从 dev check 代码，合并到 master 至关于 dev 合并到 master。
• 禁止 merge dev 到 master ，这样 dev 分支没意义。

一些问题

你们可能以为极为繁琐，好比：

• 须要根据 ISSUES 建立分支名称
• 须要通知测试测试
• 测试须要通知研发成功/驳回 等等。

研发会写 devops 工具确保你们能逐渐自动化，只是须要一些时间。能够经过一些 CLI + git 钩子/ 禅道 发送邮件等等，达到减小沟通成本。

测试职测

目前测试的同事须要收到解决的问题快速进行测试，快速通知研发结果。等待以后的邮件提醒。

运维职测

原有的 CI 脚本有小调整 (dev)，生产升级也有小调整 (不能从 qmenhu 直接拽包)

调整服务器 Git hooks ，当有 push 或 merge 请求，查询 BUG 编号，是否已经关闭，关闭的 bug 或 feature 才能够 review -> merge，不然 服务器直接驳回。

总结

一切为了团队更高效的解决问题，有充分的的我的时间。

后续任务

--- git hooks 详情 ---

• cli 程序「详情看：闲鱼技术」

• git hook 「详情看：流程规范」

• 邮件通知 「减小沟通成本」

• ISSUES 平台的自动化管理

工具

www.npmjs.com/package/zin…

我把工具发布在 npm 上了，没有开源，须要的能够借鉴一下，下次讲的时候，我会抽出一些通用的开源，如今先让内部 “打磨一下”

预览

之后单独抽一章讲下，代码很简单（5个小时工做量），主讲思路，以及如何才能作好简单的 devops，节省全部人的时间。

原文

github.com/pkwenda/Blo…