我所在的团队去年完成了从Artifactory Pro 4.14.2到5.7的升级，刚好也用到了npm、bower、Debian和Yum仓库，分享下我们踩过的坑和总结的建议，希望能帮到你。

前期准备必做 #

• 全量备份：升级前一定要做完整的系统备份（包括数据库、存储目录和配置文件），我们当时用了Artifactory自带的./artifactory.sh backup命令，同时手动拷贝了存储目录到离线存储，避免升级失败回滚无门。
• 检查兼容性：确认你的操作系统、数据库（比如MySQL/MongoDB版本）是否符合5.7的要求，4.14.2支持的一些旧版本数据库可能在5.7里被弃用，我们当时把MySQL从5.5升级到了5.6才满足要求。
• 清理冗余数据：升级前清理掉过期的构建、未使用的仓库和缓存，减少升级时的数据迁移压力，尤其是npm和bower的缓存，我们清理了近30%的冗余文件，升级速度快了不少。

各仓库升级注意事项 #

• npm仓库：
  • 5.7对npm的包元数据处理有优化，但升级后可能出现部分包的下载路径异常，我们的解决办法是重新同步所有npm远程仓库，执行Admin → Repositories → Remote → 选中npm仓库 → 点击Sync。
  • 注意检查npm的权限配置，5.7的权限模型有细微调整，之前的仓库权限可能需要重新验证，避免开发人员无法拉取/推送包。
• bower仓库：
  • bower在5.7里已经被标记为deprecated，但依然可以使用，升级后如果出现bower包无法解析的情况，需要检查仓库的Bower Settings里的Enable Bower Support是否勾选，我们当时就是因为这个选项被自动取消了导致问题。
• Debian/Yum仓库：
  • 5.7对Debian的Release文件生成逻辑有更新，升级后需要重新生成仓库索引，执行Admin → Repositories → Local → 选中Debian仓库 → 点击Refresh Index，否则客户端会提示无法找到包。
  • Yum仓库的话，要检查repo文件的URL是否正确，5.7的仓库访问路径没有变化，但如果用了反向代理，需要确认代理配置是否兼容新的Artifactory路由规则。

升级过程要点 #

• 分步升级还是直接跨版本？：我们尝试了直接从4.14.2升级到5.7，官方是支持的，但中间会自动执行多个中间版本的数据库迁移，耗时较长，建议在非业务高峰时段操作，我们当时选了周末凌晨，花了大概2小时完成。
• 监控升级日志：升级过程中实时查看$ARTIFACTORY_HOME/logs/artifactory.log，如果出现迁移错误，日志里会有明确提示，比如某个表的字段缺失，我们当时遇到了一个MySQL字符集的问题，修改数据库字符集为utf8mb4后解决。
• 升级后验证：
  • 逐个验证仓库的拉取/推送功能：让开发人员测试npm install、bower install、apt-get install、yum install是否正常。
  • 检查Artifactory的核心功能：比如用户权限、构建集成、邮件通知是否正常工作。

内容的提问来源于stack exchange，提问作者rakhee