windows - 开发人员是否应该担心对其工作站软件/开发堆栈的更新？

Question

正如我发现的那样，许多开发人员避免进行任何更新（自动或手动），因为他们担心这可能会对他们不了解的机器进行更改，并且他们正在开发的软件可能会在某些时候由于他们不知道的原因而失败.

策略 A.) 尽可能长时间地保持系统不变。

我个人喜欢让我的系统尽可能“最新”（操作系统和应用程序），因为通常我觉得以这种方式工作的麻烦更少。

策略 B.) 始终保持最新

你是什么类型的开发者？为什么？

score 8 · Accepted Answer

B. 绝对。

如果您正在开发一个更新谱系不确定的平台（例如 The Real World），那么虚拟机是一个重要的武器，但在发布时尽可能保持最新是值得的。

告诉您的用户“只需运行更新”要比尝试猜测他们可能拥有哪些补丁历史记录导致问题（或至少能够排除它）要容易得多。

如果您正在为纯粹的内部受众开发，那么您实际上只有一个问题：

公司有更新时间表吗？
- 是的：那么您需要确保您的软件在生产环境和即将出现的任何东西上都运行
- 不：可能最好解决这个问题。

score 3 · Accepted Answer

不。

这就是上帝发明虚拟机的原因。

不过，如果你是一名 OS X 程序员，那就有点遗憾了，因为操作系统中基于硬件的复制保护（你必须在 Apple 支持的硬件上运行）。

score 3 · Accepted Answer

尽可能使操作系统保持最新，最好在将补丁发布给公司其他部门之前进行系统管理员测试。

相当快地应用开发环境服务包，但首先检查虚拟机，以便您可以查看构建是否仍然有效，然后在升级开发机器之前将该构建提供给 QA 进行冒烟测试。

当您看到真正的好处时，更改开发环境（和/或平台，例如从 Java 5 升级到 Java 6），但允许将其作为具有预算时间的明确任务。理想情况下，预算项目时间以使开发人员也加快速度，以便他们能够充分利用它。不要在发布附近的任何时候这样做。

score 2 · Accepted Answer

您正在编写的软件的目标机器与您的开发机器几乎不会发生相同的情况。因此，不更新并使机器保持静止没有多大意义。

现在，目标机器..这是一个不同的故事。只要不是绝对必要，我不希望进行任何更改。

score 1 · Accepted Answer

1

一朝被蛇咬十年怕井绳。

于 2008-12-30T08:24:14.913 回答

score 1 · Accepted Answer

前几天在我的工作中发生了一个很好的例子。IT 团队对我们的开发服务器进行了更新，起初这似乎是无害的。该机器有一个无人值守的登录，必须保持 24/7 登录。Windows 的更新（我必须提取 KB）实际上会自动注销该类型的用户。我们在服务器上运行的应用程序需要有人参与的登录才能运行（是的，我知道这很傻，但那是另一回事了）。突然间，我们的系统开始出现问题，抱怨说一些正在使用的软件系统无法正常工作。

我们追踪了问题并重新登录了管理员用户，但直到大约 3 次由 Windows 引起的注销后，我们才真正意识到发生了什么。幸运的是没有造成太大的损失，但这确实意味着有些人不得不加班。

在推出更新之前，应该检查它们可能对您的操作系统产生什么样的环境影响，即使这样，也应该对其进行测试。

score 1 · Accepted Answer

B、出于安全原因。

但是，您应该在多大程度上关心应用程序中的破坏，这在很大程度上取决于您正在进行的开发类型。通常的情况几乎就像针对不同目标的交叉编译，因为几乎没有任何用户机器像开发机器那样配置。

如果它是一个 Web 应用程序，那么您的“平台”就是浏览器以及您使用的任何服务器端。对我来说，就是 ruby、rails 和插件以及 apache/mysql 等。客户端，我无法控制。服务器端，我想至少应用安全补丁（除了：请求服务器端开发人员，请在不同的周期发布安全补丁以进行功能更改！）。. 但是操作系统更新通常对我正在使用的开发服务器堆栈几乎没有影响，而且无论如何我的部署环境使用不同的操作系统（我在 OSX 和 Ubuntu 上开发并在 Debian 和 Solaris 上部署）。

如果它是桌面应用程序，那么它取决于您与平台的集成程度以及您是否可以在目标环境中控制它。由于我通常使用 Java，我认为它是平台而不是操作系统，尽管它确实需要在不同的操作系统风格和 Java 版本上进行测试。如果操作系统的某些补丁破坏了 Java，那么这是一个单独的问题。

如果您与操作系统的耦合非常紧密，那么更新依赖项很难测试，并且如果不大量使用虚拟机和快照等几乎是不可能的。此外，如果您在操作系统更改方面非常脆弱，您的应用程序可能会如果您的目标机器具有不同的软件负载或不同的配置，则失败 - 再次很难测试。

score 0 · Accepted Answer

操作系统：最新（尽管我对此并不狂热）。

小型应用程序：没有那么多。我对更新持谨慎态度，除非对我有一些附加价值，否则我不会升级。

score 0 · Accepted Answer

进行更新，但不要在开发周期的关键时期进行。使用已知尽可能稳定的操作系统发行版，并且在发布更新的频率上保持保守。

强制您的开发人员在他们即将进行签入时测试他们的代码。确保在他们进行升级之前所有测试都通过。这样可以确保他们对正在破坏的内容有所了解。

score 0 · Accepted Answer

有很多东西要看（我是根据 linux/unix 经验写的，但也应该适用于其他操作系统）：

请注意损坏的更新。损坏的更新发生了，让其他人遭受损坏是明智的。特别注意核心组件，例如 c 库（包括通常包含的 OS 接口）、链接器、编译器等。
应该谨慎地为您的产品更新组件库（或首先在测试系统/虚拟机上）。诸如 C 库之类的高度使用的库通常是可以的，但较少使用的库可能包含 API 中断或 API 中的语义更改。
编写您的软件以适应其环境：
- 最好使用各种不同配置的系统来编写
- 在不假设环境属性的情况下编写
- 在需要时更新系统，如果出现问题，可以找到根本原因并消除它。
- 除了刚性成本之外，还要特别警惕依赖于复杂系统的构建系统（它们比简单（或自动化）的构建系统需要更多的维护）。

我知道类似unix的系统比windows系统更具有独立的传统。这不会改变操作系统假设独立性的工程可靠性。所以我的建议是在新的更新可用后（通常不是第一天）尽快更新，但要确保如果事情真的发生故障，它可以很容易地回滚。如果项目中断，大多数开发人员会回滚，一个小团队致力于修复它。

score 0 · Accepted Answer

有句老话。“永远不要改变正在运行的系统”。我猜关于悲惨更新的恐怖故事很多。我只能根据我的经验来判断。如果你的软件基于“挂得很好”的组件，那么破坏它们的可能性要比快速变化的情况小得多。举个例子：我们的 IDE 基于 Win API，自 Windows 3.1（开发它的地方）以来几乎没有变化，多年来我们添加了一些不错的功能，所以我敢打赌，该软件包至少需要 Windows 2000 才能运行。但我可以向您保证，它可以从 XP 到 Windwos NT、Windows 2000、Windows 2003、Windows XP、Windows 2003-64 和“非常闪亮”的 Vista 进行许多操作系统更新。

另一方面，我无法在 Linux 上了解它基于 gtk 的端口。API 的变化是极端的。所以这是我最讨厌开源支持者的地方，你被迫一遍又一遍地重做你的工作只是为了保持实际。

另一个例子让我至少花了一周的时间将一个非常小的 Rails 应用程序从 1.1.6 版更新到 2.2 版。（而且在短短两年内）。我担心这会是最糟糕的，但有点积极地感到惊讶。

问候

windows - 开发人员是否应该担心对其工作站软件/开发堆栈的更新？

11 回答 11

Related

Reference