testing - 回归测试和部署策略

Question

我想要一些关于部署策略的建议。如果开发团队创建了一个广泛的框架，许多 (20-30) 个应用程序使用它，并且企业希望应用程序至少每 30 天更新一次，那么最佳部署策略是什么？

我问的原因是，如果 90% 的应用程序没有更改，使用每月部署更改的敏捷方法似乎会造成很多浪费(和风险)。我的意思是框架可能会在一个月内发生变化，一些应用程序也会发生变化。因为框架改变了，所以所有的应用程序都应该进行回归测试。比方说，如果一年中有 10 个应用程序根本没有变化，那么这 10 个应用程序每个月都会进行回归测试，当它们没有任何功能更改或热修复时。必须对它们进行测试，因为公司每个月都在滚动更新。

以及所涉及的风险......如果部署了一个关键任务应用程序，需要数周时间和多个部门进行测试，期望必须不断地对该应用程序进行回归测试是否现实？

一种选择是使任何框架更新向后兼容。虽然这意味着应用程序无需更改其代码，但仍需要对其进行测试，因为底层框架已更改。而且风险很大；不断变化的框架(以及部署该框架)意味着任务关键型应用程序永远无法长期享受相同的代码库。

这些应用程序共享同一个数据库，因此需要不断测试。我知道 TDD 和自动化测试，但目前还不存在。

有什么建议吗？

Answer 1

框架背后的理念是它应该是“缓慢移动的代码”。您不应该像它支持的应用程序那样频繁地更改框架。尝试让框架处于较慢的开发周期:也许不超过每三或六个月发布一次。

我的猜测是您仍在制定此框架中的一些架构决策。如果您认为框架更改确实需要如此动态，请找出框架的哪些部分经常更改，并尝试将这些部分重构到需要它们的应用程序中。

敏捷并不一定意味着对一切都进行无限制的更改。您的架构师可以对构成框架的内容设置界限，并防止人们轻易地调整它以获得可能的应用程序快捷方式。可能需要几次迭代才能稳定下来，但之后应该会更稳定。