5

在大型组织现场安装应用程序并支付支持费用的情况下，我的公司正在努力解决维护版本与“正常”版本的问题。首先让我定义我的术语：

  • 假设我们已经发布了产品的 1.0、1.1 和 1.2 版本。这些是我所说的“正常”版本，即它们是主要开发分支的下一个版本，包含所有最新和最强大的错误修复和增强功能（每个版本可能有数十个）。
  • 现在想象一下 1.0 上的一些大客户报告了一个以前没有人遇到过的令人震惊的问题。这个问题在 1.2 中仍然存在，不幸的是 1.3 不会在几周或几个月后发布。因此，我们在 1.0 分支代码以创建 1.0.1“维护”版本，其中仅包含解决问题的一项更改。

这种方法让客户很高兴，因为我们在一天左右的时间内解决了他们的问题，而不是让他们等待数周直到下一个正常版本。此外，由于维护版本只包含一个小的更改，他们不需要经过广泛的 UAT 过程，而如果他们升级到下一个正常版本，可能会有几个版本，他们可能会收到 30 或 40 （在他们厌恶风险的观点中）需要大量 UAT 的产品变更。

问题是：

  • 创建和支持我们软件的多个版本对我们来说成本很高
  • 它允许顽固的客户远远落后于最新版本
  • 它使将来最终升级这些客户的过程变得复杂，因为他们的安装与所有其他 1.0 客户略有不同（如果维护版本以某种方式对其进行了更改，则升级他们的数据库特别复杂）

所以我想知道其他人在这个问题上的立场是什么？您如何在不通过大量维护版本为您自己背锅的情况下让客户满意？例如，您是否允许某些类别的修复作为维护版本完成，但坚持其他类型的修复在下一个正常版本中完成？

澄清：编写没有错误的软件并不是一个完整的解决方案，因为上述上下文中的“问题”可能是我们产品所依赖的外部系统行为的不可预见的变化。

4

7 回答 7

3

我建议阅读多个敏捷团队的版本控制，尤其是发布分支部分（适用于 N 个团队的内容也适用于 1 个团队）。

从我迄今为止在各种答案和评论中阅读的内容中，您可能会在其中找到一些很好的建议。

于 2009-09-13T21:22:10.707 回答
2

不幸的是，这是您在与第一个客户签订任何合同之前需要决定的事情。如果合同中没有，则不存在。

对于收缩包装，你不应该关心。没有合同，因此您没有义务提供任何支持。不顾一切维持良好关系的愿望。事实上，你已经从过去的客户那里拿到了钱。永久支持他们将立即将已经获得的利润减少到一无所有。如果你真的想转向服务模式，你就不能以收缩包装的形式销售软件。（想想杀毒软件。你停止付费，他们停止更新。）

在您的网站上列出您停止支持过去版本并坚持使用的日期列表。如果他们不喜欢它，他们可以寻找新的软件。您永远无法保证未来的销售。

编辑，回应评论：然后，正如我所说，你的问题是你的合同。如果他们不给你权力说“你必须升级”或“我们不支持超过最后三个次要版本”，那么你的公司就完蛋了。展望未来，您应该确保您未来的合同确实包含此类语言。持续支持仅意味着合同所说的含义。

于 2009-09-04T05:53:43.363 回答
1

我们只为我们的客户创建一个版本，并且我们每天都进行构建和单元测试（您确实拥有两者，不是吗？）

有了这两个，我们几乎可以随心所欲地推出我们的代码，因此无需担心维护发布或正常发布。只有一个副本值得使用，而且是最新的副本。

编辑：当涉及到“天哪，我们的功能已经完成了一半，但我们仍然需要现在发布它，是的，我的意思是现在！ ”我们要做的就是标记新功能（通过使用预处理器指令）和确保在构建期间，标记内的所有代码都被简单地注释掉。

于 2009-09-04T05:36:42.400 回答
1

客户至上。您将不得不忍受支持您的软件的多个版本，因为有些客户不会升级。这是生活中令人讨厌的事实。您可以在软件开发的某些领域（例如 webapps - 任何人仍在运行原始版本的 gmail 吗？）稍微减轻它，但即使在那些类型的瘦客户端环境中，人们仍然不会升级瘦客户端（IE6 任何人？） .

您可以做的最好的事情是鼓励客户升级，也许通过默认自动更新。如果您的客户认为需要大量 UAT，那么您可能之前因为更新破坏了他们所依赖的东西而让他们不高兴，然后修复了需要一段时间才能出来的问题。如果是这样，请考虑改进您的测试和 QA 流程。

遗憾的是，我不确定您还可以做很多其他事情来改善这一点。

于 2009-09-04T05:42:02.997 回答
0

我们确实有维护和正常版本。

假设我们正在开发 5.5 版本，客户发现以前版本中的一些问题可能在 5.4.0.1 中，我们将在 5.4.1.0 中为他们提供解决方案，并在我们当前版本中进行修改，即 5.5，这样我们尝试关闭当前版本中的先前问题，并在旧版本中向客户提供新工具包

于 2009-09-04T06:31:18.153 回答
0

我的建议是始终要求客户至少尝试最新的单点版本：从 1.0 升级到 1.1，看看是否能解决他们的问题。问的第一个问题。

这里有帮助的是确保您在单点版本中不添加任何新功能，除非它们覆盖了软件中的一个大功能漏洞。制作仅用于修复错误并且最多用于删除不良功能设计的发布版本。保存新功能，让您的客户重新购买您的产品 :-)

不通过点发布引入新功能也可以降低您的客户对引入新错误的恐惧；在安装新版本时通常保留它们的原因。

如果客户仍然对您当前的单点版本有问题并且很紧急，他可以获得“修补程序”。如果当前的点版本是 1.2，则修补程序可能包含在提供给客户的 1.3 的预发布版本中。这位有紧迫感的客户现在实际上正在帮助您测试不稳定的单点发布，并且还可以帮助就单点发布中的一些其他更改提供反馈。一旦您的客户帮助您测试它​​，您也可以选择将其合并回待定点版本中的单个修复小版本。

这与 Microsoft 的服务包方法相比：经常发布修补程序，然后将它们一起收集到服务包中（-> 点发布）。在广泛发布修补程序之前，通常会与面临问题的客户一起测试修补程序。

您绝对要避免的是拥有“1.0.1-客户 A”和“1.0.1-客户 B”，您正在招致复杂性和维护地狱。

通常你应该总是将你的补丁合并回你的主线。如果您的客户正在帮助您为最新版本创建补丁，那么请接受它。

于 2009-09-13T21:00:46.453 回答
0

以下工作流程可能会对您有所帮助（但 YMMV）：

  1. 为 bugfix创建一个主题分支，在最早的时候将其分支（例如 1.0 版本），命名为例如 'foo-bugfix'
  2. 为版本（例如 1.0）的维护版本创建新分支，如果它尚不存在，并且如果此版本中存在错误，则命名为 e.,g. '维护-1.0'
  3. 将错误修复分支合并到维护分支中，如果有冲突，请解决。
  4. 如果需要，修改版本号。标记新的维护版本，例如“1.0.1”
  5. 对要支持的其他版本重复 2-4

通常，尽管您仅针对项目的最后一个版本进行维护发布（在名为“maint”或“maintenance”的分支上）。但是，我认为，如果您发现严重的错误（例如严重的安全错误）在所有受影响的版本上修复它（也许将自己限制在不太旧/仍然被广泛使用的版本）上，这是一种很好的做法。

高温高压

于 2009-09-04T15:10:42.790 回答