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

Question

正如我所发现的，许多开发人员都避免任何更新（自动或手动），因为他们担心它可能会对他们不理解的机器进行更改，而他们正在开发的软件可能会因某些原因而失败。不知道。

策略A.）尽可能长时间地离开系统。

我个人希望让我的系统尽可能“最新”（操作系统和应用程序），因为通常我觉得这样做的麻烦较少。

策略B.）一直到日期

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

Answer 1

B中。当然。

如果你正在开发一个具有不确定更新谱系的平台（例如The Real World），那么虚拟机是一个重要的武器，但是当你发布时，它应该尽可能地保持最新状态。

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

如果你是为纯粹的内部观众开发，那么你真的只有一个问题：

• 公司有更新时间表吗？
  • 是的：那么你需要确保你的软件既可以在Production上运行，也可以在任何即将发布的内容上运行
  • 否：可能最好解决这个问题。

Answer 2

没有

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

如果您是OS X程序员，那么由于操作系统中基于硬件的复制保护（您必须在Apple祝福的硬件上运行），这样可能会有点无聊。

Answer 3

让操作系统尽可能保持最新状态，最好先将系统管理员测试补丁发布给公司其他人员。

合理快速地应用dev环境服务包，但首先检查VM，以便查看构建是否仍然有效，然后在升级dev计算机之前将该构建版本提供给QA进行烟雾测试。

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

Answer 4

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

现在，目标机器..这是一个不同的故事。在那里，我不想要任何改变，只要它们不是绝对必要的。

Answer 5

一旦被咬，两次害羞。

Answer 6

这一天的一个很好的例子发生在我的工作中。 IT团队推出了对我们的开发服务器的更新，起初看起来似乎无害。该机器无人值守登录，必须全天候登录。 Windows的更新（我必须提取KB）实际上会自动注销该类型的用户。我们在服务器上运行的应用程序需要有人参与登录才能运行（是的，傻，我知道，但这是另一个故事）。突然之间，我们的系统开始变得混乱，并且投诉使得一些正在使用的软件系统无法正常工作。

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

在推出之前，应检查更新是否会对您的操作系统产生何种环境影响，即使这样，也应对其进行测试。

Answer 7

B，出于安全原因。

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

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

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

如果你非常紧密地耦合到操作系统，那么更新依赖关系很难测试，如果没有大量使用虚拟机和快照等几乎是不可能的。另外如果你在操作系统上变得那么脆弱你的如果您的目标计算机具有不同的软件负载或不同的配置，应用程序可能会失败 - 再次非常难以测试。

Answer 8

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

小应用程序：不是那么多。我对更新保持警惕，除非为我提供一些附加价值，否则不会升级。

Answer 9

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

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

Answer 10

有很多事情需要关注（我是从linux / unix体验中写的，但事情也适用于其他操作系统）：

• 请注意更新损坏。破碎的更新发生，让别人谨慎 遭受破坏。要特别注意c库等核心组件 （通常包括OS接口），链接器，编译器等
• 应谨慎地（或在测试中）更新产品的组件库 system / vm first）。高度使用的库，如C库通常都可以，但是 较少使用的可能包含API中的API中断或语义更改。
• 编写您的软件以容忍其环境：
  • 优选使用各种不同配置的系统来编写
  • 在不假设环境属性的情况下编写
  • 在需要时更新系统，如果出现故障，请找到根本原因 消除那个。
  • 要特别警惕复杂的系统相关构建系统（它们需要很多 除了刚性成本之外，还需要比简单（或自动化）更多的维护。

我知道unix like系统比windows系统更具独立性。这并没有改变OS假设独立性的工程健全性。所以我的建议是在新的更新可用之后很快更新（通常不是第一天），但要确保在事情真正中断时可以轻松回滚。如果项目中断，大多数开发人员都会回滚，一个小团队正在努力修复它。

Answer 11

有句老话。 “永远不要改变正在运行的系统”。我想有关悲惨更新的恐怖故事很多。我可以从我的经验中得知。如果你将软件建立在“井上”组件的基础上，那么打破它们的可能性远远小于快速变化的速度。一些例子：我们的IDE基于Win API并且自Windows 3.1（开发它）以来运行几乎没有变化，多年来我们添加了一些好处，所以我打赌包需要至少运行Windows 2000。但我可以向你保证，它可以通过Windwos NT，Windows 2000，Windows 2003，Windows XP，Windows 2003-64以及“哦，闪闪发光的”Vista从XP中获得许多操作系统更新。

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

另一个让我至少工作一周的例子是将一个非常小的rails应用程序从版本1.1.6更新到2.2。 （而在短短两年内）。我担心这会是最糟糕的，但有点令人惊讶。

此致