本来想把这些命令写成一个脚本，可是 kill 老进程的执行要切换用户，一时间没有太多时间调试这个，且要执行的批量命令也不多， 因此，还是直接复制粘贴了。好在发布的时候，机器的编号是逐渐递增的，可以预测每批次发哪几台机器， 这就容易多了：只要在每批次发布之前，先 kill 掉将要发布的机器的老进程即可。
会影响线上服务么？ 由于还有其他服务器在处理消息，且凌晨的消息量极少，因此 kill 几台机器的进程不会对线上服务有影响。
写好发布文档之后，已经 十一点半了。 该提发布申请了。
在提发布申请之前，得先运行并单测全部通过。到单测平台上运行了下，发现报错： groovy 与 spock-core 的版本不兼容。
郁闷了。在本地运行是 OK 的，为啥在这个节骨眼报错了。 看了下工程的配置，还是比较老的版本。想想可以升级到较新的版本，对任务运行应该没有影响。于是从核心工程拷贝了更新的版本号，并修复了一个单测文件。
为了简单，根据报错只把 groovy 的版本升到了 2.0.1 ， —— 给自己买了个坑。在程序的世界里，因果命中注定。
突然想到， 除了 S ，还有一个附属应用 s， 代码与 S 相同 ，但只运行对比任务。嗯， 这个应用也要发布， 也在预发验证下。
我在 QA 也部署了应用 s ，可启动日志显示：访问交易配置表报错了：用户名被拒绝。这是怎么回事呢？ 在发布之前，有一些配置变更我提交了。我想到应该是运维同学更新过，不会有问题。 QA 没法验证， 只好上预发验证了。
于是，我在预发也部署了 s 应用。启动日志没报错，可也没消费日志。想了想，也许之前就没有吧。 应该是 OK 的，就做发布前的准备去了。
突然被拉到一个群里，是预发交易配置库访问出错排查。由于我集中精力在准备发布，因此对这个并未投以太多关注。但群里好像说是比较严重的事情，坚持要查明白，似乎说我故意配错了用户名和密码，以致于访问到错误的地方，险些造成安全事故，还连累了很多同学耗费时间来查问题。可我只是提交了被别人改动的配置（并且我相信是运维同学改动且应该是正确的），并没做出格的事情。难道，我一不留神就犯下了错误 ？
事情原委是：DBA 同学杨大侠监控到交易配置库有大量访问错误，而且还来自于不同的机房，认为这是很大的不合理。初步排查到，访问出错来自于预发的 s 应用。这有什么关联呢？ 我一时也有点懵逼，仿佛处于云山雾绕。
####&####
我提交了发布申请，开始发布 s 应用。未料，线上也报错了。这可奇怪了，我对比了下 S 与 s 的 交易配置表的用户名和密码，完全一样的啊 ！ 在 跳板机上用 mysql 连接了下，也是通的； S 在预发部署也没报错，这可奇怪了。
杨大侠提醒： DB 连接的 jdbcURL中有 & 这样的字符。 我突然想到了， 在 QA 遇到过这个问题，因为高版本的 mysql 不支持这个老的语法，需要将这个变成 & 本身。
哪里还藏有 & 这个字符呢 ？ 重新再check 了下 s 应用的配置。 发现，交易配置表的配置有两处，其中一处是完全一样的，但还有一处。 重复出现的 DB 配置，真坑啊！
修改之后，就没有报错了。排查这个错误耗费了将近三个小时。发布完 s 应用后，已经三点了。
S 应用的发布似乎顺利一些。发了几台，没有报 DB 访问错误，或者其他奇怪的错误。
四点半了， 刚发了几台机器，发现有错误： RefundBizNsqInput 的 bean 找不到，任务启动报错。这个任务是消费退款消息，写入退款数据，供订单导出来计算退款状态及金额的。如果这个数据有误，可能会影响订单状态的展示，误导商家发货。
内心有点崩溃。 这可怎么办呢？ 继续发布完成 ？ 这样会导致这个任务大量报错， 退款消息无法消费， 引起上述问题， 造成故障； 如果暂停发布，等待下午发布，一则现在新老混布有较大风险，二则下午发布风险更大； 重新发布，已经快到 5 点的发布截止窗口了，稍有延迟，就要走紧急发布了。
思前想后，还是趁这会清净，赶紧发完吧。于是，我紧急看了下代码，发现 RefundBizNsqInput 不在组件自动 scan 的包路径下。 于是将这个任务涉及的组件类都移到了可以被自动扫描组件的路径下，修复了下单测。此刻，如果要再验证 OK 再发布的话，恐怕会耗时太长。 于是，我做了个大胆的决定，不验证就直接发布。因为只是通过 IDE 的重构功能挪了下包路径，理论上是不会有问题的。 其实心里还是有点虚的。