让 sdk 包静默升级的 SAO 操作，你见过几种？

拓展阅读

让 sdk 包静默升级的 SAO 操作，你见过几种？

业务背景

有时候为业务方提供了基础的 sdk 包，为了保证稳定性，一般都是 release 包。

但是每一次升级都非常痛苦，也不可能写一个一步到位的 jar 包，因为业务一直在变化。

那有什么方式，让 sdk 包静默升级呢？

今天学习到一个骚操作，和大家分享一下。

方式1-snapshot

以 java 的 maven 包管理为例，如果使用 snapshot，那么就可以随时方便的升级包内容。

优点

非常简单，maven 天然支持。

缺点

• 包信息不够稳定，一般为了追求生产的稳定性，都会要求去 snapshot。

• 升级失败，不兼容等，没有回滚的余地。

方式2-nexus 等内部仓库直接替换

方式：直接替换指定版本的仓库中的包。这种方式的核心和上面类似。只不过是看起来不是 snapshot，但是依然无法保障安全。

方式3-shell 脚本结合 CI

方式：使用 shell 脚本，在升级的时候，先备份，再替换。

流程：一般结合 ci 流水线使用，部署打包的时候替换包版本到指定版本，相比较而言更加灵活，也有回旋的余地。

缺点：要求比较多，比较麻烦。且要求应用必须通过 ci 流水线部署，否则就会被绕过。

注意点

1）需要保证 jar 版本之间的向前兼容性，避免升级导致问题。

2）应用环境比较复杂，可能会出问题。所以一定要逐步的升级，让用户测试环境经过验证。

3）提前通知用户，让用户知道这个事情。而且允许用户不做升级操作。

小结

这种方式给我的感觉是无可奈何，但是又非常巧妙。

上一次有这种感觉的，还是运维怕磁盘爆，预留 500MB 放一个垃圾文件，磁盘满了直接移除，快速解决问题。

你在日常工作中，见到过哪些 SAO 操作？