22
33![ OSS] ( https://static.cnbetacdn.com/article/2018/0821/6516ac17b422c31.png )
44
5- - 当前应用部署流程中，dev 开发环境的包名为写死状态，每次生成的包名为项目名.jar，test/prod 环境为管理版本，需要从应用内部读取版本号 ，配合项目名在每次打包时生成唯一的 jar 包名。
5+ - 当前应用部署流程中，dev 开发环境的包名为写死状态，每次生成的包名为项目名.jar，test/prod 环境为管理版本，需要从 Github 发布的 release 中读取版本号 ，配合项目名在每次打包时生成唯一的 jar 包名。
66- 结合以上实际情况，对项目打包做如下约定。
77
88## 1 开发环境打包
99
10- - 开发环境不支持版本管理，不用修改版本号，但是建议结合当前提交的 PR 中对程序的修改内容写出一条更新语句，放到 update.md 中
11- - 开发环境打包默认从 master 分支拉取代码
10+ - 开发环境不支持版本管理，不用修改版本号，但是应该结合当前提交的 PR 中对程序的修改内容写出一条更新语句，放到 update.md 中，且该语句后应该附上 PR 和 Issue 链接。
11+ - 虽然运维已经用不到 update.me 文件，但是为了在提到测试环境时完整还原整个过程，应在每次 PR 过程中在 updaet.md 中附上上述内容。
12+ - 开发环境打包默认从 master 分支拉取代码。
1213
1314## 2 测试/正式环境打包
1415
@@ -25,27 +26,30 @@ jar {
2526
2627- 如上，现版本号为 v2.0.1，建议向 test 环境提交代码时更改最后一位数字，即改为 v2.0.2
2728
28- ### Step 2: 修改 update.md 文档
29+ ### Step 2: 整理 update.md 文档
2930
3031``` text
3132# 版本升级基本内容
3233- 当前版本 v2.0.2
3334- 替换版本 v2.0.1
34- - 替换操作:
35+ - 替换操作:
3536 - 登录流程中加入了验证码元素，当登录失败超过三次需要输入验证码，最后一次输入错误15分钟后可不用输入验证码
3637- 回滚操作
3738```
3839
39- - 如上，所写内容应概括本次提交中的要点。
40+ - 如上，所写内容应概括本次提交中的要点，需注意以下几点
4041 - 版本号仅在向 test 提交的那一次进行更改。
4142 - 当多人协作在 dev 环境开发时，每次向 dev 环境的代码提交也应如实记录提交内容。
4243 - 等到某次向 test 环境提交代码时，之前多次在 dev 开发中提交在 update.me 文档中的记录可作为本次 test 提交的记录。
4344 - 向 test 环境提交代码成功后，程序员有责任清空 update.md 中** 替换操作** 和** 回滚操作** 中的内容，方便下一波 dev 迭代开发过程中的更新记录。
4445 - 向 prod 提交代码时，应整理之前的 update 记录，进行提炼，总结出本次正式环境发版的更新内容。
4546
46- ### Step 3: 提交代码到 release 分支
47+ ### Step 3: 提交 Release
4748
48- - 运维默认从 release 分支向测试/正式环境拉取打包代码，故在向 master 分支发起 PR 并合并代码饿基础上，应再向 release 分支合并代码。
49+ - 运维根据 release 发版动态拉取 master 分支代码进行测试/正式环境的打包。需注意以下几点
50+ - release Tag version 是打包时实际上采用的版本号，应与 application_version.gradle 中的版本号一致，且与 update.md 中的当前版本字段一致
51+ - release Title 与 release Tag version 保持一致
52+ - release 描述文字，复制 update.md 中的** 更新内容** 和** 回滚操作** 中的条目对齐即可
4953
5054### Step 4: 通知运维打包
5155
0 commit comments