敏捷开发最佳实践
1.整体流程
- 1.需求规划：产出 ->用户故事
- 2.Sprint Planning Meeting(Sprint计划会议)：产出 -> Sprint Backlog(任务列表)
- 3.需求确认：产出 -> PRD
- 4.Daily Scrum Meeting：每次站会
- 5.Coding: 产出 -> Code
- 6.Test：产出 -> Test Report
- 7.Sprint评审会议（Sprint Review Meeting)： 产出 -> 会议纪要
- 8.回顾会议：产出 -> 会议纪要
2.版本控制
整体采用Gitflow，结合自身实际，总体流程如图
- 1.从prod切出dev分支
- 2.从dev分支切出特性分支
- 3.特性分支新功能开发完，提交代码到dev分支
- 4.确定无误后，研发同学提交merge request，将dev分支合并到test分支
- 5.测试同学同意合并，代码合并后触发自动构建，推送镜像到自建镜像仓库，然后自动部署
- 6.测试环境确认无误后，测试同学提merge request，将test分支合并到pre环境，代码合并后触发自动构建，推送镜像到自建镜像仓库，然后自动部署
- 7.prod环境操作同上述第六步。
2.1 Commit要求
commit msg应当清楚地描述本次的代码改动都涉及哪些内容。这对测试同学来说，能够清楚本次改动是否需要回归测试，避免遗漏；对于研发同学来说，在后续出现问题的时候，能够方便定位到问题可能位于哪次commit中。
敏捷开发中，建议频繁提交改动，每完成一个小的功能即可提交。一般来说，commit msg可以参考如下格式：
- feat： 新功能,新特性（feature），带上需求编号
- fix： 修复bug，如果有bug编号，要求带上bug的编号
- docs： 文档（documentation）
- style： 代码格式修改(比较小的代码变动, 功能保持不变)
- test： 测试用例修改,或增加测试代码
- refactor：代码重构,内部处理逻辑/算法逻辑发生较大改变.（即不是新增功能，也不是修改bug的代码变动）
- chore： 构建过程或辅助工具的变动, 比如构建流程, 依赖管理等.(无法判断的提交推荐用这个)
2.2 tag要求
在每次正式发布版本的时候，都需要给版本打上一个tag，tag通常形如 vX.Y.Z，其中X为主版本号，Y为次版本，Z为为维护版本号，具体含义如下
- X = 主版本号 (重大升级, 不同主版本的库之间是不兼容的)
- Y = 次版本号 (增量升级,增加一些新的接口但保留原有接口.高版本号的库向后兼容低版本的库)
- Z = 维护版本号 (仅修复 Bug) (修改错误,改进性能等,不添加新接口,也不更改接口.在主版本和次版本相同的前提下,不同维护版本之间完全兼容)
2.3 版本更新日志
在给版本打tag之前，需要在readme中写上本次版本更新的内容。
2.4 sql的更新与维护
当修改涉及到数据库表结构的变动时，需要在sql/update/中新增表结构更新的语句，运维同学做版本发布的时候，需要先执行更新语句，然后再启动服务器。同时，在sql/all.sql文件中，需要维护全量的表结构数据。