- 完整流程：拉取代码-->编译打包构建-->统一存放构建包-->停服务-->部署构建包-->启服务
先拉取代码；
然后进行编译打包构建；
将打好的构建包传到指定存放位置；
部署并重启服务；
- DEV：拉取代码-->编译打包构建-->统一存放构建包
研发提供构建脚本，用于构建符合测试环境可用的构建包，并放到统一位置；
- QA/OP：统一存放构建包-->停服务-->部署构建包-->启服务
测试环境：测试去统一的位置拿构建包，部署到测试环境；
线上环境：由OP去统一的位置拿构建包，部署到线上环境；
| 环境 |
使用 |
部署 |
构建 |
| DEV |
DEV |
DEV |
DEV |
| TEST |
QA |
QA |
DEV |
| STAGE |
QA |
OP |
DEV |
| PROD |
USER |
OP |
DEV |
例：
mvn clean install -P [dev|uat|ywcs|qa1|qa2|qa3|prod|...]
mvn clean install -pl account-web -am -P [dev|uat|ywcs|qa1|qa2|qa3|prod|...] -Dmaven.test.skip=true;
- DEV、TEST环境参数文件存储在GIT中；
- STAGE、PROD环境参数文件由OP管理；
- 配置文件与代码分离，不放在jar包中；
建议配置文件格式：
xxx/*[dev|uat|ywcs|qa1|qa2|qa3|prod|...].properties
PS: 配置文件配置项一定要写明注释
- 由开发维护构建脚本，建议构建脚本存储到git上；
- 构建脚本通过传递参数的方式构建不同环境的不同应用；
例：
build_cmbc.sh -e [dev|uat|ywcs|qa1|qa2|qa3|prod|...] -p [we|exchange|pay|user] -a [we-home|we-mgmt|admin|service|schedule|...]
- 符合以上规范的可以集成到jenkins中进行自动构建；
- 研发提供相关服务的部署脚本或者命令后，测试编写部署脚本，并集成到jenkins中进行自动部署；
现状：
研发编写了构建脚本，通过传递参数可以构建不同环境的构建包；
已经集成到jenkins，但是对jenkins依赖严重，没有写成单独的构建脚本；
- 交易所、对账、账户中心等
- 基金
- 引擎
- 搜索、消息中心
现状：
we_services：
研发编写了构建脚本，通过传递参数可以构建不同环境的构建包；
已经集成到jenkins；
we_rsps：
研发编写了构建脚本，通过传递参数可以构建不同环境的构建包；
已经集成到jenkins；
后期预计常用git flow方式；
we_ruleengine：
新增服务，按照规范进行；
we_search&we_messagecenter：
新增服务，按照规范进行；
现状：
有构建脚本，大部分时间测试在维护，
不同环境配置没有存储在git上，需要替换很多配置文件；
脚本和配置文件都缺乏统一管理；
dubbo.properties: 配置项需要手工调整；
很多配置项打在核心jar包中，耦合度太高；
老代码依赖新的支付中心的jar包，更新版本需要单独打jar包；