版本管理说明文档?产品版本项目/子项目所定义的版本,两节:x.y如智计划1.2,那么这个产品版本号为1.2,我来为大家讲解一下关于版本管理说明文档?跟着小编一起来看一看吧!
产品版本
项目/子项目所定义的版本,两节:x.y。如智计划1.2,那么这个产品版本号为1.2。
工程版本
代码构建产物的版本。工程版本号通常为四节,x.y.z.build。x.y 继承产品版本号;z在敏捷项目团队中是冲刺编号,在瀑布团队中为流水号。该节用于区分不同的研发、上线周期;build为构建流水号,通常由构建工具自动生成。
测试代码同样也有工程版本号。目前测试代码没有发布流程,也没有通过工具发布,所以z.build由测试团队人员自行决定。原则上每一次正式交付,变更z。
发布标签
每一次发布到生产,在git代码库中,给对应的commit标记一个标签,值为部署物的工程版本,即x.zy.z.build。
目标统一分支管理策略以及定义。版本化一切,最终提高项目的团队合作效率、加速新功能开发和发布管理。
原则
项目名称 |
开发启动时间 |
移交测试时间 |
回归时间 |
上线时间 |
XX项目 |
9月1日 |
9月15日 |
9月25日 |
9月26日 |
开发流程
序号 |
时间 |
事项 |
描述 |
命令 |
说明 |
1 |
9月1日 |
从master新建分支 |
从master创建分支。分支名称:feature/11-Add_redis_support |
git checkout master git pull git checkout -b feature/11-add_redis_support git push --set-upstream origin feature/11-add_redis_support |
所有参与人员都提交到此分支 |
2 |
9月2日 |
设计、编写代码与测试 |
提交、提交、提交 |
git add --allgit commit -a -m "move display name to redis" git push | |
3 |
9月3日 |
开启MR,以开启讨论和Review |
从gitlab的站点中创建一个MR。 |
如果并未做完,MR以"WIP:"开头 | |
4 |
9月15日 |
讨论、修改、测试 |
讨论方案、修正review的改进项。 |
git add . | |
5 |
9月16日 |
循环修复bug并不断push到远程分支。 |
git commit -am "move on and on" | ||
6 |
…… |
每日merge master代码到分支。 |
git merge master | ||
7 |
9月25日 |
自动化、人工验收全部通过,MR通过 |
master代码可以发布时,打上版本号标签,1.1.0 |
git tag add "1.1.0" git push --tag |
选中 "Squash commits when merge request is accepted.“ 选中 "Delete source branch when merge request is accepted" |
8 |
9月26日 |
部署 |
生产环境部署master。 |
通告其他分支开发人员尽快merge master代码 |