建议不使用package[option]
,而是显式地独立下载依赖。优点是方便显式地管控库版本,最大限度避免依赖冲突;缺点是需要维护的库的数量会增加。
如果升级Django和DRF等基础库版本,在不确定升级是否会造成不兼容时,遵循如下步骤。
- 选择合适的“绿地项目”。选择发生异常时影响最小、最容易更变的。比如,没上线的优先,未正式公开发布的优先,规模小的优先。
- 在“绿地项目”中升级库版本,并完整地运行全部单元测试和服务测试,通过后完整地进行发布部署流程。直到上线到生产环境以后一段时间无异常表现,即可界定为升级成功。通常在一个正式版本中解决。
- 逐步扩大范围。保险起见可以再选择一两个主要微服务试验一轮。
- 升级本基础镜像和Django项目模板的依赖版本。前者影响未配置在本项目requirements文件,后者影响新项目。
未来计划通过配置中心逐步代替,以方便直接对整个系统切换并减少发布频率。
具体思路为:
- 在测试环境直接切换并通过所有的单元测试、服务测试、端到端测试。
- 对生产环境提交代码和配置更新,类似于其他配置更新一样管理即可。
如果配置中心不易支持容器环境本身的更新,则放弃此思路。