至此，新工程的整体和主要部分没问题了。还需要做一些简化，比如去掉一些无用的模块和文件，优化 pom 里的 jar 引用等，保持工程的简洁与干净，没有赘余。
接下来就要考虑发布了。
工程改动太多了，有点失控的感觉。 在发布之前，找几位有经验的同学帮忙一起 check 下是明智的选择，也是必经的流程。一位是一直帮我排查 QA 同步问题的子杰同学， 一位是见识比较广能力不错的王立同学，因为他作为后端同学解决了react 容器部署的问题，让 S 的新界面又重新问世啦！靠谱，厉害！还有一位是我的有伴水王，也是很踏实的。
CR 的同时，也要验证这个工程是否能保证原有的任务都能正常进行。
前面谈到， 订单同步使得搜索和详情的任务都是 OK 的，也就是最重要的任务没问题；
有些任务是与第三方交互的，在 QA 是无法验证的。 好在：这个工程里绝大部分都是访问 DB， ES， HBase 的组件，绝大多数的业务逻辑都在配置的任务里。可以说是“将基础技术设施与业务逻辑相分离而实现配置化“的典范做法。因此，从基本层面看，只要验证部分任务， 覆盖到所有的组件类别， 就可以看作是验证了所有任务。
既可以把这种做法看成一种巧妙的方式，也可以看作是某种取巧和偷懒。这种方式还是会有漏网之鱼。
使用新工程部署之后，一直在观察中，没有跪过。 有点安心了。 在发布前晚，突然发现： 跪掉了。 天 ！ 难道还有什么细坑 ？又得继续观察和排查细坑了 ！ 恐怕要延期发布了。
幸好，当天早上， 有伴告诉我，他重启过一次，运维同学也重启过一次，但是没启动成功。 我立即想到，可能他们是用老的 zan 版本启动的， 因为不兼容导致失败。我用 zan 的新版本启动是 OK 的。
很快确认了这一点， 虚惊一场。
孙子曰：“夫未战而庙算胜者，得算多也，未战而庙算不胜者，得算少也；多算胜，少算不胜，而况于无算呼？”
距离计划发布时间只有几个小时了。 这个工程的发布胜算在 92% 以上， 有 8% 的不确定性。胜算如下：
最主要的订单同步任务是没有问题的；
十几个的任务及子路径，我验证了大部分是可以正确输出的；
组件代码无改动，只是工程结构变了；
在 QA 和 预发环境运行稳定。
不确定性如下：
有一个任务是外部交互的，无法验证； 四个任务是边缘业务，不太好构造测试用例（其实是有点懒，结果是受了惩罚的）； 但这些任务所使用的组件，都在其他被验证过的任务中使用过了，因此，理论上也应该是间接被验证了；
引入了 youzan-boot 的包，还有以前工程里的 jar 包，可能存在一些细微的不兼容的坑，未被发现。
不管怎样， 胜算还是很大的。在发布的时候，再细心一些， 应该不会出什么问题。
在预发部署的时候，发现新的进程并没有正常起来，必须先手动 kill 掉原来的进程，再部署新的工程，才能让新进程正常启动和运行服务。 这一点尤为重要， 否则很容易出问题。
如果能对预发出现的问题敏锐地感知，有时预发的问题真的是神明的指示。前不久做过的一个项目中，需要做一些交易配置的变更。在预发验证拼团订单的时候，订单状态没有正常流转，经排查日志发现：预发的请求竟然发到线上去了！ 联系营销同学得知，订单的后续通知，取决于接收最后一个参团订单的请求的机器所处的环境。比如说吧，拼团发起者的下单请求在 T1 机器， 拼团参团者的下单请求在 T2 机器上。 机器 T1 切换到了新的配置， T2 还没有。 此时， T2 将向营销发送消息，营销处理消息完成后，向交易机器 T3 发送回送消息。如果 T3 还没有切新配置，就可能导致走不下去。 发现这个问题后， 仔细思考了下，发现在 下午正常发布窗口发布是有风险的。因为如果正好在那个时间段有很多拼团活动，势必会导致很多拼团订单的状态流转有问题，不仅会对商家的交易有影响，还要应对后续复杂麻烦的数据修复。 想想，还是辛苦一点，凌晨发布好了， 此时拼团活动极少， 且有更多时间来验证项目改动和回归业务。
经过沟通，决定在凌晨发布。安全上线。
由于要赶在新进程起来之前手动 kill 老进程，这个时机得把握好， 为了避免误操作，临阵手忙脚乱，因此，必要写个发布文档， 写清楚每一个步骤要执行的命令， 在真正发布的时候，只要简单的复制粘贴就可以了。