要借鉴的项目
核心代码的改造步骤
第一步
webservice 核心 用maven管理, 在不动任何代码的前提下建立依赖关系. 不改变包名的前提下建立多个公用moudle(数据库访问,pdf生成,基础类等),实现 webservice和核心的共用的代码抽离到新moudle中, 一处修改,两处生效.
(批处理暂时不,因为包名改变了,且同名文件很多内容也不是完全一致的)
(第一步之前就可以做jekins发布了, 同时梳理好每个环境, merge rebase 版本管理)
第二步
, 核心内的公共代码拆分,乐观来说可以每个模块是一个moudle,每个模板可以单独打成war包,
公共组件的拆分好处是解耦,方便以后的技术更新,基础功能都是友好的接口访问,做框架替换也方便
第三步
对于某个新加菜单页面的redmine , 引入流行的现代化的开源框架开发前台和后台(特别是前台的表格和后台的数据库访问,且已弹出新窗口的方式开发这样可以脱离落后的ie5), 前期两套开发模式并行.之后可以定计划分批次的将核心页面迁移到新开发模式里. 最终抛弃掉中科软的开发方式
核心发布流程的改造
在代码改造的第一步就可以做jenkins自动发布.
Trunc流对应dat环境 即28环境, 每天中午和晚上自动发布,开发也可以自己点build手动发布, 这个环境开发用来做dat测试
Pre流对应发 pre环节和手动发 uat环节 (?)
release流对应发生产环境
每个环境发新版本之前从上个流rebase, 然后从下个流merge
- Trunk是空的, PRE是空的, UAT是空的 Prod是空的
- Trunk开发6月大版本 每天 dat自动发布
- 6月大版本开发结束. Trunk锁流, 6月大版本从 trunk merge到 pre, pre开始测试6月大版本内容. trunk开锁 trunk开始7月大版本开发
- Trunk提交 7月大版本任务, pre提交6月大版本发现的pre bug,
- Pre测试完成. Pre 锁流. 6月大版本 从pre merge到uat, uat开始测试6月大版本内容. Pre保持锁流
- Trunk提交 7月大版本任务, pre 保持锁定, uat流提交6月大版本发现的 uat bug
- Uat测试完成, uat锁流, 6月大版本 从uat merge到prod. 6月大版本结束.
- 此时假设7月大版本没有开发结束: Trunk提交 7月大版本任务 pre锁定 uat锁定. Prod提交生产bug.
- 当7月大版本开发结束, trunk锁定. Uat开锁,将prod的6月大版本做的生产bug修复merge到uat. Uat锁定. Pre开锁,将6月大版本的生产bug修改和uatbug修复merge到pre, pre锁定, trunk开锁, 将6月大版本的 生产bug uat bug pre bug merge到 trunk. Trunk 锁定.
- Pre开锁, trunk 的7月大版本内容merge到pre(仅7月大版本, 不merge6月的bug修复) ,pre开始 测试7月大版本, trunk开锁,开始开发8月大版本
- Pre提交7月大版本的pre bug. Pre测试完成后锁pre,将7月大版本和7月大版本的pre bug修复 merge到uat
- Uat 提交7月大版本的uat bug, uat测试完成后锁uat,将7月大版本和7月pre bug修复和uat修复merge到prod , 生产发布7月大版本结束.
(生产环境对应stage环境(预生产), 用于修复生产bug后的内部测试. )
好处
- 问题快速响应
- 每个redmine必然对应一个版本, 每个特定的时间点每个流都是只能提交某个版本的redmine的,管理上更严谨, 没有redmine号或者没有在正确的流提交是提交不了的
- 每个流要做的事情很清晰
- Bug规范管理(每个分支的bug必须正确提交)
等等等
补充
Svn不匿名. Svn与redmine关联 做版本和redmine状态的关联
https://blog.csdn.net/wangduqiang747/article/details/107152740
先做这个再做merge 版本管理
.
.
.
.
.
整个文档常识ok?