非升级不可？
最近团队引用的UI库升级3.x.x版本后，各个小组项目可能都需要更新。那不更新，行不行？不更新当然也行，也就是维护成本会高些，页面性能会慢些，开发新页面会更耗时些，而已已也。就好比出一趟远门，别人都是开车，自己骑的却是带有历史色彩的二八大杠。所以该更新还是得更新，万一这趟远门是去相亲，别人都领着人都跑了，自己还是半路，那单身就得找原因了。
如何升级？
网上查了半天，多是只管依赖升级，不管项目死活的。这种捡芝麻丢西瓜的事咱直接忽略。好在之前做B端项目的时候，有过几次大的项目升级【angularjs->vue，vuetify 1.x.x -> vuetify 2.x.x】。那我就结合之前的经验，谈谈如何升级项目【独木舟 -> 帆船】。
1. 创建独立环境。 【万一帆船没造成，独木舟还能将就着用】
怎么理解呢？
就是创建一个跟当前待升级项目并行的一个运行环境，两者（最好）没有任何交集【如果确定互不影响的情况下，部分逻辑可以公用，例如基础css，纯函数等】。
如何创建？
如果条件允许，业务流程没那么复杂，能重新启动一个项目是最好的，这种方式也是最方便的；等新项目稳定后，直接替换域名映射项目即可。如果条件限制，维护项目数量过多，容易崩塌，也可以在当前项目新开个path【webpack多入口】，再利用依赖别名来实现：一个项目，两套依赖并行运行。【注意样式UI库的样式隔离，避免相互影响】
2. 更新。 【造帆船 - 最苦最累最有意义的过程】
怎么更新，从哪开始更新？
首先确保细读过待更新依赖包的升级日志。有了这一步，基本可以大刀阔斧的去干了。直接将原项目复制一套出来，根据升级日志哪里变动改哪里。先把确定的变动给它改喽，就像考试一样，先把会的填了，再把精力聚焦到不会的上面。
报错了怎么办？功能不支持？样式不兼容？
记住我们现在是处理一类问题。报错了需要根据错误提示信息去挨个检查，可能是引用方式不对，也可能是属性名字变化，按类处理。功能不支持需要查阅文档新版的写法和引用方式。样式不兼容，大概率是库的组件属性使用方式变了，或者属性名称变了，对症下药即可。
最最痛苦的是什么？
最最痛苦的是当你只想升级一个核心库的时候，发现其他库都得升级（很有可能就是上面某个报错报出来的）。仿佛掉入了升级深渊，望不到头，因为你永远不晓得，下个库版本更新，会不会又得升级下下个库。所以如果真遇到这种事（我遇到过），上面的更新步骤先别急，先把所有库都兼容统一后，再开始上面的更新步骤。
3. 测试。 【船检 - 很关键的一步，直接决定之前的累死累活值不值得】
在我看来，这一步的意义要比步骤2“更新”更重要。如果造出来的帆船都是漏水的，那相当于之前的一切白忙活。所以测试对于升级项目来说，很重要，也很有必要。有多重要？说得不夸张点：如果测试工作没做好，那这个升级意义真不大。
谁敢直接上个未知的项目到生产，让客户使用？有人说了：我就敢。那这种伙伴是典型的月入30万的，是个狠人。这个效果，跟后端伙伴删库跑路差不多一个性质了。
怎么测？
如果有单元测试UT加上e2e当然是最好不过的，相当于飙车，系上了安全带。如果没有，也ok，只是谨慎些，不系安全带，跑慢点即可（多测测各种场景）。但不管有没有这层安全带，都需要我们根据路由去罗列所有的页面链接，以及其使用场景。
4.回滚。 【两手准备 - 就好比大船上肯定有很多救生圈，甚至小游艇】
小心使得万年船，新升级的工作体量一定很大。一旦出了问题很难应对过来的。就好比之前花了一个月开发的是一个流程页面，现在花一个月升级的是N个流程页面。升级改动的内容又都是相似的，一旦出了问题，基本就是崩塌式的，所以回滚很重要。
怎么回滚？
理想情况下，最好有个后端配置页面，总开关+页面级别的开关。打开的时候老页面地址直接重定向到新的内容，关闭的时候，默认继续浏览老的页面即可。当生产有问题的话，可以根据具体问题，控制具体开关。共性问题，操作总开关；个性问题操作页面级别开关。
5. 收尾。 【如果帆船海上航行数月，没啥问题，甚至开始批量生产，那独木舟也就不需要了】
如果项目运行一段时间（根据项目体量确定）后，没啥幺蛾子，那就可以直接删掉老代码，换成新代码即可。为了方便，尽量项目中统一管理新旧差异。如果是不同链接，可以新加个baseRoute，例如"v2/"。如果是组件切换，改route映射首地址即可。所以更新的时候，尽量结构跟老的保持统一，方便后续收尾。
风险
项目肯定是持续迭代的，所以当有新功能的时候，是开发两套，不是一套了，所以一定，一定要估算好排期。
