需求评审
第一阶段研发和产品对需求的时候,主要关注什么
主要关注的: 价值
必须要做的: 排期
设计文档
在开发任何需求前是必须写设计文档的
设计文档中什么是干货: 图
因为没人愿意读一堆文字
其中最重要的有几点
- 各种架构图,主要的有,整体功能架构图,整体技术架构图,各系统关系图,数据流转图
- 数据库表字段定义和索引设置
- 业务流程的实现,画流程图
- 性能优化和提升方案
- 稳定性保障上线回滚方案
然后评审
开发阶段
最重要的是
- git分支清晰
- 代码质量(无bug,无低级错误,清晰简洁)
关于git:
首先:至少需要4个分支。dev,test,uat,master
dev:开发的分支,始终保持和master一致,这个分支的作用就是防止很多人一起王master分支合并,冲突,把master搞混乱
test::测试的分支,每个人的改动都可以提交上去测试自己的功能
uat:预发布的分支,保证提交的都是test分支测试过的没问题的代码
master:线上的分支
理念是每个功能单独从dev拉一个分支
命名 dev-姓名-xx功能-年月日
所有人各自开发自己的分支,开发完
- 合并到test测试
- 合并到uat测试
- 合并到dev不用测试,只处理冲突,然后合并到master测试
测试阶段
必须有测试和UAT和回归测试三步
测试阶段
开发本地自测完成(只有后端的可以单元测试或,有前端的本地跑前后端页面测试),
- 把自己的**dev-姓名-xx功能-年月日 **合并到test分支
- 编译test分支代码并部署test分支到测试环境
- 测试去验证功能并提交bug,研发修改bug
- 重复1-3步,直到清空bug
UAT阶段
- 研发把自己的 dev-姓名-xx功能-年月日 合并到uat分支
- 编译uat分支代码并部署uat分支到uat环境
- 产品和业务去验证功能并提交bug,研发修改bug
- 重复1-3步,直到清空bug(此处严格来说需要重复的是测试阶段的1-3步,但是如果问题很小,也可以直接在uat重复1-3步)
回归测试阶段
- 研发把自己的 dev-姓名-xx功能-年月日 合并到dev环境,处理冲突,没任何问题后再合并到master分支
- 编译master分支代码并重新部署master分支到最开始的测试环境
- 测试去验证功能并提交bug,研发修改bug(理论来说不应该有bug)
- 重复1-3步,直到清空bug(此处严格来说需要重复的是测试阶段的1-3步,然后uat阶段的1-3步骤,但是如果问题很小,也可以直接在master重复1-3步)
上线阶段
本阶段是最关键的阶段
- 一定要有上线报告,并且通知全体
以下全部内容需要截图
主要包含:
- 本次改动的功能
- 灰度步骤和时间和回滚等方案
- 对改动功能监控和验证的方案
- 对基础的自查(如代码,日志,分支等等)步骤是否全部完成
- 本次改动相关的全部文档链接,PRD,设计文档,代码CR链接等等
- 本地改动的埋点推广流量监控(就是统计这次功能上线后有多少调用量,多少人在使用)