使项目保持最新版本的技术

只需将其作为优先事项,并在进行过程中升级即可。如果您保持最新版本的更新,与一次更新5个版本相比,会有更少的破坏性更改。

也许可以创建一个分支并对betas进行测试更新,以便在使用该版本的RTMs时(如果您担心使用betas),您可以意识到即将出现的问题。

我同意这里关于经常更新的其他评论。如果您等待的时间太长,您将在项目生产力中注意到这一点。

我们的做法如下。

• 一 团队中的人员,获取最新版本,并确保所有测试都运行。
• 他还记录了升级过程。
• 运行所有测试,确保它们运行。
• 用户界面的人工烟雾测试
• 签入/确保它构建在构建服务器上

这样我们就不会在升级过程中降低团队的生产力。注意,如果没有单元测试,这将非常困难。

提前更新,经常更新

如果您等待,这将是越来越困难,所以把更新系统的高度优先权。开发人员大多喜欢站在最前沿,所以他们不会太在意,关键的挑战是向管理层推销这一理念。

在一个一个工具的升级中,一步一个脚印的方法总是好的。如果您需要回滚到旧版本,那么也会更容易。大爆炸方法更难,很多事情都可能出错。

让我们现实一点,每次更新都会花费您和您的团队时间来切换到新的工具版本,但经过一段时间后,团队会学会如何处理它,切换版本时的压力会小得多。

从管理的角度来说,除非有令人信服的理由,否则不要升级。你必须看看升级给你的项目带来了什么。如果升级没有好处,就不要这样做。显然这不是一个硬性规定,但我知道的大多数团队没有时间无缘无故地升级系统,他们忙于功能请求和bug修复。我建议在以下基础上进行升级:

1. 高效地和您的 改进,否则会降低你的工作效率 内在的硬件需求。
2. 特征 已添加您或您的 客户/客户想要并且可以接受 [直接]优势。
3. 影响您当前或将来的 近期未来架构。
4. 许可证/支持原因。如果你是 您有权使用的软件 当你仍然支持 升级或者,如果你在 找到支持文件 因为它很难升级 这当然是必要的。
5. 你正在做的项目的某些方面 工作受到以下因素的直接影响: 软件可能是 使用它并进行测试 在功能上,它可能是一个 不会给系统添加显著的负载 项目
6. 项目或它所依赖的软件 现在可能是添加 更新到项目计划中。 重大变化意味着更大的风险 升级路径困难,应该 在预定的基础上,而不是

不升级的具体原因:

1. 软件、安装和回归测试都要花钱。因此,需要一个令人信服的升级理由。
2. 新软件通常有缺陷或具有未知的“功能”。因此,许多人选择在最新版本之后保留一个版本。
4. 兼容性问题。升级会破坏东西,最好尽可能多地跳过增量升级,以避免破坏兼容性的更新,这些兼容性可能会在下一次更新中修复。

我建议保留项目使用的所有软件及其版本和上次升级日期的列表(以及其他重要信息,如许可信息、支持信息等)。每年评估此列表中的每个项目一次,以确保您不会错过任何与您可能错过的升级原因相匹配的更新。此列表中包含旧版本/日期和更新版本的软件可能足以激励管理层进行升级。