记一次上线

上周我们团队做了个release，包括4个feature，都是遗留系统的改动，替代一个旧有的服务，撤销一个不再使用的功能，更改一些页面的下拉列表信息, 每一个都是小的改动点。在整个准备和部署的过程中，我们遇到了各种问题，所以在本文总结一下。

这次release覆盖了6个应用，从第一个feature做好到现在上线，长达6个月，也许你会问为什么会拖这么久，为什么一次上这么大的改动。原因很多，对第三方系统的依赖，假期和暴风带来的change freeze，是耗时长的原因。
而起初为了节约人力而决定合并的release, 最后都一分没少的回报给了复杂度和风险，同时，这期间发生了重要人员的流动（DEV，QA，IM），都增加了沟通和交付的成本。

可以说，这次release是持续交付的反面教材，值得反思。

除去关于持续交付的思考，还有很多实操中的教训，应该谨记：

关于部署：#####

1. 部署用的环境及时注册，通知其他团队。做到不测不部，防止影响其他团队测试
2. release pipeline 不配低环境
3. release pipeline 配的JAVA 版本注意分stage，避免使用默认值，e.g.有的pvt 需要JAVA8
4. release pipeline 配置所连接的DB env要经过协商，达成一致
5. instance 上的 certificates 没有配置
6. 代码要在Dev分支上，需要release的时候再拉release branch
7. 团队的每个成员都对应该对部署脚本仓库负责，遵守命名规则

关于测试：#####

1. 第三方服务的测试环境不稳定，需要开发前统一匹配问题，多沟通
2. 第三方系统的测试，要注意每个字段的返回数值,以及配对情况。尽量明确scope

关于沟通：#####

1. offshore 沟通困难的时候，及时和Tech lead 和交付负责人沟通，请求帮助
2. 和所有将参与部署的人员都沟通好，信息一致
3. 权限的核对，尽早（e.g.代码仓库，应用测试）

对我自己：#####

因为各种原因，我有点稀里糊涂的成为了drive这次release的人，对于老系统不甚熟悉的我，“受宠若惊”。而且最后阴差阳错的做了这次release 的测试，倒是一项额外的收获。

1. 相信你的团队，每个人都已经在当时的状况做到了最好
2. 沉着，冷静
3. 带宽不够，及时求助
4. 多看一些老系统的东西，这些老零件早晚有一天坑到你

晓
2017.5.1