环境构建与部署规范

环境构建与部署规范

一 流程与环境角色

1.1 流程和职责

• 完整流程：拉取代码-->编译打包构建-->统一存放构建包-->停服务-->部署构建包-->启服务

• DEV：拉取代码-->编译打包构建-->统一存放构建包

研发提供构建脚本，用于构建符合测试环境和线上环境可用的构建包，并放到统一位置。

• QA/OP：统一获取构建包-->停服务-->部署构建包-->启服务

测试环境：测试去统一的位置拿构建包，部署到测试环境。
线上环境：由OP去统一的位置拿构建包，部署到线上环境。

1.2 环境

环境	说明
DEV	开发测试环境，开发完成后研发要先进行自测，确保基本流程能够走通后再提测
TEST	测试环境，研发自测完成后提测，测试在测试环境进行测试
STAGE	备机环境，测试通过后，测试发上线邮件，运维部署到备机，测试在备机上测试
PROD	生产环境，备机测试通过后，运维上线到备机提供给用户使用

1.3 角色

角色	说明
开发	开发人员，负责开发代码
测试	测试人员，负责测试代码
运维	运维人员，负责生产环境运维，办公环境基础设施维护

1.4 环境角色关系

环境	使用	部署	构建
DEV	开发	开发	开发
TEST	测试	测试	开发
STAGE	测试	运维	开发
PROD	用户	运维	开发

二 规范细则

2.1 获取代码

• 统一获取代码，传入分支号即可快速获取最新代码
• 目前使用的是统一的获取代码脚本，大家可以参考使用

规则：
checkout code: branch name
例：
cgit.sh -e prod -p we -b release_20160824

2.2 编译打包构建

2.2.1 维护构建脚本

• 由开发维护构建脚本，建议构建脚本存储到git上
• 构建脚本通过传递参数的方式构建不同环境的不同应用

规则：
build: mvn clean install... / build.sh ....
例：
build_cmbc.sh -e [dev|test-uat|test-ywcs|test-qa1|test-qa2|test-qa3|prod|...] -p [we|exchange|pay|user] -a [we-home|we-mgmt|admin|service|schedule|...]

2.2.2 根据传递的不同环境参数进行构建

例：
Java：
mvn clean install -P [dev|test-uat|test-ywcs|test-qa1|test-qa2|test-qa3|prod|...]
mvn clean install -pl account-web -am  -P [dev|test-uat|test-ywcs|test-qa1|test-qa2|test-qa3|prod|...] -Dmaven.test.skip=true;
Node：
sh ${APP}-build-for-ucloud.sh ${real_branch} ${target_machine_dir} ${mobile_backend} ${home_backend} ${exchange_backend}

2.2.3 不同环境参数文件管理

• DEV、TEST环境参数文件存储在GIT中
• STAGE、PROD环境参数文件由OP管理
• 配置文件与代码分离，不放在jar包中

建议配置文件格式：

/-[dev|test-uat|test-ywcs|test-qa1|test-qa2|test-qa3|prod|...].properties

当有多个配置文件的时候：

[dev|test-uat|test-ywcs|test-qa1|test-qa2|test-qa3|prod|...]/.properties

PS: 配置文件配置项一定要写明注释

2.2.4 jenkins持续集成

• 方案一（Java）
  
  （1）符合以上规范的可以集成到jenkins中进行自动构建，测试只需要填写简单几个参数(环境、平台、应用、代码源等)即可进行构建。
  
  （2）研发提供相关服务的部署脚本或者命令后，测试编写部署脚本，并集成到jenkins中进行自动部署。
  
• 方案二（Node）
  
  （1）若不采用方案一，而又需要集成到jenkins中进行自动构建，则需要研发自行完成jenkins任务的配置。
  
  （2）研发提供相关服务的部署脚本或者命令后，测试编写部署脚本，并集成到jenkins中进行自动部署。

2.3 部署

• 编写统一部署脚本，完成部署完整过程
• 目前已支持tomcat、node、java服务等部署方式，覆盖当前所有的服务

• 部署规则

    1 transfer packages
    2 stop service
    3 overwrite packages
    4 start service
    5 check

• 部署过程统一用脚本实现

例：
p2p应用部署：
new_deploy.sh -p we -a home,mgmt,schedule
node应用部署：
node_deploy.sh -a mobile -e uat

三 调整进程

3.1 新代码调整(8.31前完成)

• 前端（we_frontendx）

现状： 
研发编写了构建脚本，通过2.4中方案二的方式，构建不同环境的构建包；
已经集成到jenkins，但是对jenkins依赖严重，没有写成单独的构建脚本。

• 交易所、对账、账户中心等（we_services）
• 基金（we_rsps）
• 引擎（we_ruleengine）
• 搜索（we_search）、消息中心（we_messagecenter）

现状与调整方案：
we_services：
研发编写了构建脚本，通过2.4中方案一构建不同环境的构建包，已经集成到jenkins。
we_rsps：
研发编写了构建脚本，通过2.4中方案一构建不同环境的构建包，已经集成到jenkins。
后期预计常用git flow方式。
we_ruleengine：
新增服务，按照此规范进行。
we_search&we_messagecenter：
新增服务，按照此规范进行。

3.2 老代码改造(9.15前完成)

• 主站、mobile（we_renrendai4）

现状与调整方案：
现状：
有构建脚本，大部分时间测试在维护。
不同环境配置没有存储在git上，需要替换很多配置文件。
脚本和配置文件都缺乏统一管理。
dubbo.properties: 配置项需要手工调整。
很多配置项打在核心jar包中，耦合度太高。
老代码依赖新的支付中心的jar包，更新版本需要单独打jar包。

调整方案：
老代码改造，按照此规范进行。