Safe Package Upgrades — Process Walkthrough

好，今天我们来讲一下安全升级演练，它非常直观地展示了Salesforce开发中一个很重要的概念——共享责任模型。 想象一下这个场景：我们作为开发者，发布了一个托管包的1.0版本，里面有一些类和方法，订阅者拿到了这个版本后，为了让功能更贴合自己的业务，可能会去重写、或者说覆盖掉我们原本实现的一部分逻辑。这完全没问题，也是平台提供的灵活能力。 但接下来，如果我们发布了2.0版本，把原来那些被覆盖的功能，在底层做了新的、本地的实现，情况就不同了。对于订阅者来说，如果他们直接升级，但没有做任何锁定版本的动作，那他们之前在1.0上精心调整的重写逻辑，可能就和新版本的代码打架了，出现错误或者不符合预期的结果。这是很头疼的事。 这个问题的根源，就在于升级时缺少一个版本固定的保护。所以，解决方案其实分两层，需要开发者和订阅者各负其责，这就是共享责任。 对订阅者而言，最稳妥的做法是，把自己写的Apex类明确固定到1.0版本上。这样，哪怕底层包升级到了2.0，这些类运行的时候，还是会继续调用1.0版本的上下文，你之前做的重写依然有效，不会被新版本意外冲掉。这是订阅者这边的责任。 那开发者呢？我们不能只让订阅者去兜底。我们自己的代码，也要主动实现向后兼容。这里就要用到一个很关键的方法，叫 System.requestVersion( )。通过在代码里使用这个方法和适当的条件逻辑，我们可以判断出当前包正在被哪个版本调用。比如说，如果发现调用方仍然基于1.0版本，就继续走老的兼容路径；如果是2.0的新调用，就走新的优化逻辑。这样两个版本就能和谐共存，不会突然崩掉。 最后，要实现顺利升级，光靠代码还不够。双方还需要通过清晰的文档、发行说明来提前沟通。开发者在发版说明里就要讲清楚：新版改了哪些底层实现，哪些地方容易被覆盖影响到，推荐订阅者怎么做版本固定。订阅者看到这些说明后，也可以有的放矢地去检查和管理自己的固定版本。这样互相配合，整个升级过程才会平顺，不出意外。 所以，总结一下，安全升级演练告诉我们：版本升级不是一个人的事，开发者和订阅者必须像齿轮一样咬合起来，开发者用System.requestVersion做好向下兼容，订阅者用版本固定保住自己的定制，再配合上清晰的文档同步，就能一起完成一次漂亮、平稳的升级。