升级与维护

项目暂时没有升级需求时，可以继续使用当前版本。本章是一份供以后参考的维护指南，不要求现在下载新版、更新依赖、执行迁移或重新部署，也没有指定必须升级到的目标版本。

初始化后的项目已经包含模板源码，后续修改由项目自己管理。模板更新需要比较差异并合并，不能像替换一个普通依赖包那样自动完成。

先分清几种“更新”

当前 CLI 没有自动合并现有项目的 upgrade 命令，saavo refresh 刷新的是登录凭据，也不是刷新项目源码。

什么时候值得安排升级

先从实际需要出发：新版是否修复了自己遇到的问题，是否涉及正在使用的安全或运行组件，是否提供了确实需要的能力。如果变化只涉及未使用的功能，可以记录并暂缓，不必为了版本号一致而改动业务。

需要处理的问题也不一定要求全量合并模板。可以采用一组相关修复，但必须检查它们依赖的类型、数据结构、配置与测试，不能只复制最显眼的一个函数。

本章分为三篇

1. 评估与合并模板更新：确认模板来源，比较旧模板、新模板和自己的项目，决定引入哪些变化。
2. 数据与配置迁移：处理已有数据库、配置、资源绑定和持久化业务标识，识别不兼容变化。
3. 验证、发布与维护记录：验证旧数据与新行为，按发布阶段判断恢复方式，保留下一次维护需要的信息。

没有数据库或资源变化的更新，可以只阅读第一篇和第三篇，不需要为了“完成升级流程”额外编写迁移。

现在可以保留的信息

这些记录有助于以后比较，但不需要现在改变项目运行方式：

• 初始化时取得的模板名称、版本和源码来源。
• 项目初始提交，以及当前应用自己的版本与发布提交。
• 自己修改过的核心模块、长期定制和已知限制。
• 当前 Worker 和资源对应关系，以及原有凭据的安全保存位置。

CLI 会将新项目的 package.json 版本初始化为 0.0.1。它属于应用自己的版本，不能用来反推模板版本。模板来源不明确时，应注明未知，再根据初始文件和取得源码时的记录确认，避免猜测。

遇到正在发生的故障，先查故障排查。日常发布自己的业务修改，按部署上线操作即可。