补丁对客户不利吗？[关闭]

在办公室，我们只是度过了漫长的一段时间，在那儿我们太频繁地发布补丁了。在此期间快要结束时，我们平均每周要进行大约三个补丁。

除了这对于开发人员来说非常不利之外，我想知道客户对此会有什么想法。我自己问了一个问题，得出的结论是，我不知道经常更新的软件。但是，对于最接近的情况，我并不在乎，因为补丁很快就可以应用。

收到这些补丁的客户彼此之间有很大不同。有些人确实在等待其他人并不真正关心的补丁，但是他们都得到了相同的补丁。更新客户软件的时间少于30秒，因此我认为与时间无关的任何问题。他们确实需要注销。

因此，我的问题更加详细：获取更新是否经常向接收方发出“负面”消息？

当然，我可以问顾客，但是我不在那个位置，也不想“唤醒熟睡的狗”。

PS：如果有什么我可以改善的问题，请发表评论。

与计算中的许多事情一样，这取决于。如果这些补丁是对客户对新功能或改进要求的回应，那么您的公司将被视为具有响应能力。另一方面，如果您的补丁是对错误报告的回应，则您的公司将被视为无能。

不管别人怎么说，到目前为止，对客户进行软件测试是检测错误的最昂贵的方法。这是一种虚假的经济；您认为自己获得的免费劳动力远远被客户服务工作量，打破软件开发生命周期以及失去客户信心所抵消。

我觉得在附近发布几个补丁对公司影响不大。总是让我觉得他们没有经过足够的前期测试，开发人员没有能力或者管理层不知道自己在做什么。

话虽这么说，令牌的另一面是释放彼此接近的多个补丁程序，这表明该公司正在对其产品采取积极的方法，并正在继续为消费者改进其产品。

我更倾向于认为前者是大多数人从消费者的角度看待它的方式，但是直接与他们交谈（显然）将是最佳选择，但同时也会在客户群中引发他们可能会遇到的问题。最初并没有意识到。

越来越多的公司效仿Chrome的步伐，并且越来越频繁地发布客户。

实施短发布周期的先决条件是轻松进行升级-例如，在chrome中，升级无需用户干预即可完成应用程序启动，如果用户始终保持其应用程序运行，则他会收到一个次要标志建议他在方便的时候重新启动应用程序，然后应用程序将努力使他在重新启动后返回到以前的状态。

这种方法使客户感到高兴，因为他不需要知道每个更新，并且由于功能发布频繁出现，因此错误修复版本也会受到欢迎。

另一方面，如果补丁是在显眼的show-stopper错误之后出现的，并且又是成簇出现的，因为较早的补丁无法修复该错误或创建了一个更大的bug，请放心，您的客户会闻到它的味道。这肯定会不好地反映供应商的专业声誉，并降低供应商的感知软件标准。连续交付在很大程度上取决于有效的单元测试和集成测试，以确保其成功。

关于不与客户交谈以“让睡狗撒谎”的问题，我认为这是错误的策略-客户不是盲人，也不是傻子。我相信与客户的良好沟通只能使他们放心，他们是您的首要任务，并且您会接受他们的批评。如果您几次发布了错误的发行版，而您没有听到他们的抱怨-您一定要担心-这不是他们没有注意到，而是更有可能的是他们只是忙于为您寻找替代品...

专门针对已发现问题的客户的补丁显然需要尽快退出。

我曾在大型公司看到过软件，然后采取了这样的方法，即其他客户将以固定的预定时间间隔将这些补丁作为Service Pack获得。通常，由于修补程序需要花费一些精力在客户环境中进行安装和测试，但是在您的情况下，它只能用于减轻您所关注的效果可能带来的影响。

我还看到有人提倡在存储库或网站上放置补丁，以便客户可以下载并安装他们想要的补丁。这会在知道客户拥有哪些补丁时产生问题，因此当他们遇到问题时打电话时，您必须确切地确定他们正在运行的代码，但要谨慎对待。然后，当发行捆绑了许多补丁的软件包时，您可以强迫人们升级到其中一个更大的软件包。

安全补丁例外。众所周知，总部位于华盛顿的一家大型软件公司在发布关键的安全补丁之前要等待一个月的第三个星期四，而有关该黑客的信息已经泄漏出去，并迫使他们尽早陷入更大的尴尬之中。

Google chrome通过非常频繁地自动更新来解决该问题，它们也需要您重新启动程序（重新启动chrome，或者注销）。他们现在已经对浏览器进行了常规操作，人们甚至不再考虑它。但并非所有人都能成为Google。

SaaS应用程序通过在后台进行更新来解决整个问题。

但是，最重要的是，除非您非常频繁地进行持续集成或使用用户要求的新功能进行更新，否则我认为我们仍然处在人们希望您在发布之前进行大量测试的时代。如果您不愿与您的客户见面并谈论错误修复的频率，您可能没有进行足够的测试。在发布代码之前，您是否已承担了多少风险？只要知道是什么，就有理由发布非常早的错误代码，但是我认为您需要对已知质量有很好的了解，这意味着了解并控制自己的时间来了解质量。