1、整体发布流程,应该遵循:
a、同一个war包(保证功能的一致性),依次在dev、pl完成验证后,再提交到online环境发布。
b、依赖配置中心,区分不同环境的配置,进行区分。
2、DEV环境,可直接登录服务器,发布
3、PL环境,通过发布系统进行
4、online环境发布,需要遵循下面原则进行发布:
a、按计划实施发布,hotfix除外,并提前知会相关干系人与影响方,特别是测试与运维。
b、编写上线邮件,注明发布应用、上线人、发布内容、发布时间、war路径、版本、wcc配置、db修改、checklist等内容,参考上线邮件:
上线备注 | 是否检查 | |
上线级别 | A | |
ApplicationName | xxxx |
|
version | xxxxx |
|
War包路径 | /deploy/xxxxxxxxxx.war |
|
Wcc配置 |
| |
Sql脚本 | DML: |
|
DLL:无 |
| |
配置表修改配置 |
|
|
功能及依赖 |
| |
功能点 | 1、xxxxxx | |
依赖方 | 无 |
|
业务方 | 无 |
|
发布 |
| |
依赖系统发布顺序 | 无 |
|
机器清单 |
|
|
发布顺序 | 先发一台,然后三台三台发 |
|
回滚 |
| |
回滚方案及步骤(考虑依赖系统,配置回滚和代码回滚的顺序) | 回滚代码 |
|
回滚脚本 | 无 |
|
回滚配置 | 无 |
|
Checklist | 是否验证成功 | 验证时间 | |
检查war包版本是否正确 | (War包没有带版本号,现在暂时无法通过版本号检查) |
|
|
Cmdb上查看tomcat是否成功启动 | xxxxxxxx |
|
|
接入dubbo的,检查服务是否注册成功 | 通过dubboadmin检查服务是否正常更新 |
|
|
验证上线功能点 |
|
|
|
验证通用线上回归功能 |
|
|
|
通过cat监控图看服务是否正常(持续观察) | 通过Cat系统检查服务是否恢复正常打点 |
|
|
发送上线成功邮件 |
|
|
|
c、发布时,和运维直接对接,对于集群发布,先发布一台,并进行服务端日志、服务管理、cat调用验证通过后,在不影响服务中断的前提下,再进行分批次发布。