故障更新表明存在更深层次的问题
Windows 10将于2015年7月在东京发表显然，2018年10月10日的Windows更新不是最成功的更新。
有关计算机
上文件丢失的消息很快出现，Microsoft停止分发更新。 从那时起，该
错误已得到
修复 ，现在在重新发布之前正在测试新的更新。
这不是Windows上第一个出现问题的更新-在以前的更新中，我们看到了诸如
严重的硬件不兼容性之类的东西-但它显然变得更糟了。 我们大多数人都知道备份，但是实际上，许多数据（尤其是家用计算机上的数据）没有备份，并且丢失非常不愉快。
Windows即服务
在Windows 10中，计划从根本上改变开发过程。 微软希望更好地响应客户和市场的需求-并且更多地发布新功能。 Windows 10被视为Windows的“最新”版本。 同样，所有新开发的内容都将成为Windows 10的更新，每年通过更新系统提供几次。 这种新的开发模型称为Windows即服务。 经过一番混乱之后，微软
决定每年进行两次功能更新 ：4月和10月。
这些努力是成功的。 Microsoft将为新模型发布有用的新功能，而不会强迫用户等待三年来更新主版本。 例如，已发布了一种方便的功能，用于
在虚拟机中以
无形方式启动Edge ，从而为恶意网站提供了更好的保护。
用于Linux的Windows子系统 （WSL）使您可以在Windows系统上本地运行Linux程序，它已成为开发人员和管理员的工具。 对于普通用户而言，好处很难被注意到，但是可以提及与
SteamVR兼容的 VR功能，
改进的游戏性能以及
更暗的主题 。 尽管改进并不显着，但总体而言，当前的Windows 10肯定比三年前发布的Windows 10更好。
在Windows仅每三年更新一次的日子里，很难想象WSL会成为有用的工具。所有这些都很好，如果不引入Windows即服务模型，几乎不可能完成某些事情（至少成功完成）。 例如，WSL的开发基于用户反馈。 用户谈论了发现的不兼容性，并帮助确定了开发新功能的优先级。 我认为，如果没有每六个月进行一次稳定的更新，WSL就不会获得如此大的发展动力-没有人愿意等待三年才能看到微小的改正。 例如，这样一个重要的程序包就可以正确开始工作。 定期更新会奖励人们出现错误消息，因为每个人都真正看到及时纠正了错误。
Windows即服务模型的问题在于质量。 该模型和安全更新的先前问题已经削弱了人们对Windows 10更新策略的信心，有经验的用户
认为 Windows 10中每月安全更新的质量下降，并且一旦发布半年一次的功能更新就很
疯狂 。 这些投诉也有悠久的历史。 Windows 10发布后不久，更新不佳
就成为引起人们关注的原因 。
删除文件的最后一个问题使专家认为，
每年可能有太多的两次功能更新 。 雷德蒙德（Redmond）应将其数量减少到一个，微软（Microsoft）应
暂停开发新功能，并仅修复错误 。 一些人
担心该公司危险地严重丧失对更新的信任，对于某些Windows用户，这种信任已经丢失。
这些并不是第一个要求Microsoft减慢功能更新的电话-有人担心IT部门和普通用户都很难消化所有这些信息，但是由于最新更新存在明显的问题，这些电话变得尤为重要。
这与频率无关，但是正在准备如何进行更新
但是那些坚持每年更新一次而不是两次更新的人错了。 问题不在于输出频率。 问题出在Microsoft开发过程中。
为什么问题不在于条款？ 我们可以查看其他操作系统的更新时间表。
一方面，macOS，iOS和Android的更新频率较低，因此您可能会感到Microsoft过于热情。 另一方面，有这样的成功更新频率的先例：对于Ubuntu，每年有两个版本，而Google的Chrome操作系统（如其Chrome浏览器）每六周收到一次更新。 如果您使用的不是OS，则Microsoft Office Insider程序每月运行一个频道，每月向Office用户发布新功能-开发人员可以在不引起过多抱怨的情况下处理工作，同时提供
源源不断的新功能和修补程序。 Visual Studio团队还经常发布其开发环境和交互式服务的更新。 显然，Microsoft的团队已经很好地适应了现实，他们的应用程序会定期更新。
我们将超越本地软件的范围，着眼于网络和云服务。 在那里，Microsoft和其他公司越来越多地引入
连续交付 。 通过足够数量的自动测试后，系统中的每个更新将自动部署到生产服务器。
当然，这些项目在复杂性上都无法与Windows相提并论。 Ubuntu可能拥有更多种类的软件包，但无论如何，其中许多都是独立开发的。 事实仍然存在：Windows的规模异常大-而且这些组件前所未有地集成到单个代码库中。 在某些地方，Windows代码异常旧。
当然，这些因素使Windows的开发复杂化，但是，真的不可能一年克服两次更新吗？ 这根本不是重点。 您只需要正确的开发过程。
Windows 10将于2015年发布时（我的所有图标和“开始”菜单在哪里？）植根于历史的过程
微软没有透露Windows 10开发过程的具体细节，但是该过程有一些可观察到的特征（如何将新功能发送给内部人员，内部人员构建中的错误类型）以及公司内部的一些信息。 所有这些间接事实都表明了开发过程的劣势。 他保留了该公司在三年Windows版本中使用的开发过程的一些相似之处。 时机已经下降，但是基本方法没有改变。
在过去，当大型发布之间间隔了两到三年时，Microsoft进入了一个分为以下几个阶段的过程：
- 设计和计划；
- 组件开发；
- 整合
- 稳定。
大约4到6个月的规划和设计，6到8星期的密集编码，然后4个月的集成（每个功能通常在其自己的分支中开发，因此它们都需要收集并组合在一起）和稳定化（测试和纠正错误）。 在产品开发过程中，此循环重复两次或三次。 Windows将进行三个迭代，第一个迭代是一个原型，接下来的两个是真实的。 阶段的持续时间可能会有所不同，但基本结构已在公司中广泛使用。
在此过程中，有些事情显而易见。 也许最引人注目的是，出乎意料的是，很少有时间直接花在开发新代码上：对于Windows发行来说，这是整个三年期间的两个间隔，每6-8周一次。 在计划/设计阶段和实际工作的产品之间会花费大量时间。 这就是不能将此过程描述为“灵活开发”的主要原因：新功能已牢固地嵌入最终产品中，因此很难根据反馈进行更改。
开发与错误修复之间的分离也是一个问题：在开发和集成阶段，软件的可靠性和稳定性非常差。 集成功能没有从根本上进行测试（因为测试将在以后进行），并且从不相互使用（因为它们都是在集成阶段之前在自己的分支中单独开发的）。 然后在长期稳定阶段通过测试，错误报告和错误纠正将软件混乱程度提高到可接受的水平。 在此过程中，您需要反复提高产品的可靠性。
Nadella在2015年向世界介绍Windows 10新世界不是那么新
在新世界中，我们看到整个公司周期需要七个或八个月的时间。 尽管两次发布之间只有六个月的时间，但是下一个周期的开始是在上一个周期完成之前进行的-对于内部人员来说，这可以从“跳过先行”小组的成立中明显看出。
通常，每次更新都是在一个相对安静的时期开始的，其中包含一些可见的更改，然后在几个月后引入了大的更改-以及大量的错误。 在更新前大约一个月，我们看到所做的更改数量急剧下降，并且非常重视错误修复，而不是新功能。
正如Microsoft员工自己描述的那样，开发的最后几个月包括“告诉”阶段，然后是“询问许可”阶段的一个月。 在“通知”阶段，会将默认情况下接受更改的策略通知Windows管理。 在“请求许可”阶段，通常只允许进行真正的重大更改，通常每天仅进行少量更改。
例如，10月更新的第一个版本（代号RS5）已于2月14日发布给内部人员，而4月更新的稳定版本（RS4）则在两个月后的4月16日发布。 直到3月7日，RS5才收到任何重要的新功能。 在5月，6月和7月期间添加了许多功能，然后在8月和9月仅进行了少量更改。 八月份甚至删除了几个小功能，因为很难为十月份的发布做好准备。
当然，过程有所改变。 例如，经过数月的时间，新功能会出现在预构建版本中。 这表明新功能的集成似乎发生得更早了-随着功能的发展，最终并没有出现在一个大型合并包中。
质量下降
但是有关键的相似之处。 最重要的是，故意将错误代码集成到通用数据库中，并且测试和稳定阶段用于解决任何问题。 微软甚至警告说，这一刻甚至得到了明确的认可：宣布一个
新的初步程序集 ：“像往常一样，在开发周期开始时，程序集可能包含可能很痛苦的错误。 如果这给您带来不便，则可以考虑切换到慢速更新周期（慢速振铃）。 在那里，组装仍将具有更高的质量。”
我们实际上在RS5中看到了这一点。 去年10月，随着更新，他们为OneDrive引入了一项新功能：占位符，可在云中显示未本地下载的文件。 每当应用程序尝试打开文件时，OneDrive都会透明地从云存储中提取文件并将其保存在本地，并且该应用程序甚至都不知道该文件最初不是可以在本地访问的。 如果磁盘空间用尽，RS5版本
实现了清除本地存储中复制的云文件
的功能 。
这是一个非常聪明，有用的功能，可以改善与云存储的集成。 这是一个新代码； 有一个内核驱动程序，提供了云同步代码（用于上传文件和下载更改）与文件系统中的图标之间的链接。 还有一个API（似乎第三方也可以将此功能用于其同步服务）。
Windows预构建使用绿色的“死亡屏幕”而不是蓝色，因此易于区分可以合理地假设Microsoft将对此新代码进行一系列测试：创建文件，检查同步，通过保存图标删除本地副本，通过下载实际文件打开图标，完全删除文件等等。 有一些用于操作文件和目录的基本操作，并且在任何灵活的开发过程中，都有一些测试来验证所有操作均按预期进行，并且API会执行应做的事情。
此外，合理地假设任何破坏测试的代码更改都将被拒绝并且不允许集成。 该代码必须是固定的，必须先通过测试，然后才能进入Windows的主分支，更重要的是，它必须进入Beta测试人员。
但是，许多初步构建中都有一个错误：删除与OneDrive同步的目录时，系统挂起。 该错误不仅已集成到Windows代码中，而且还发布给了最终用户。
在发布之前而不是之后测试软件
这表明了Windows开发的一些基本原则。 要么根本没有针对该代码的测试（有人告诉我，是的，允许我不进行测试就集成代码，尽管我希望这不是规范），或者测试失败被认为是可以接受的，非阻塞性的问题，并且允许开发人员集成显然不可行的代码正常工作。 在外面，我们无法确切地说出到底发生了什么-也许甚至是两种方法的结合-但是，没有一种可以说是好的。
对于Windows的较早版本，可以认为这是更合理的选择-毕竟，它们是在自动测试时代之前开发的，实际上可能没有测试。 但是OneDrive徽章不是Windows的旧部分；它是一个全新的功能。 没有充分的理由说明为什么没有可靠的测试集来测试新代码的基本功能。 而且，除非修复了已知的有缺陷的代码，否则
绝对不应该将其包含在代码库中，更不用说将其发送给测试人员了。
结果，Windows 10的开发仍然遵循旧的原则。 随着稳定性和可靠性的下降，新功能被注入数据库。 假定在测试和稳定阶段会将代码库提高到可接受的水平。
自动测试不足和/或忽略测试错误，意味着Windows开发人员无法确定更改和更正不会引起连锁反应。 这是“询问许可”开发阶段的来源：随着更新完成，需要最小化更改的数量，因为Microsoft不确定每个更改的范围和影响是否独立。 这种信心仅取决于大规模的严格测试基础架构：您知道更改是安全的，因为所有测试均成功通过。 无论公司针对Windows进行哪种测试，显然都不足以获得这种信心。
但在其他方面，微软的举动似乎具有确定性。 公司有很多测试； 有人告诉我Windows的完整测试周期需要数周。 这个完整的周期实际上是执行的，而不是在实际投入生产的装配上执行。 一个例子是2018年10月的更新：该代码在9月15日进行了汇编，并在10月2日进行了公开。 不管哪个RS5构建都经历了完整的测试周期，这都不是我们实际收到的结果，因为完整的测试周期需要太多时间。
这是一个有争议的立场。 如果对代码进行了后续更改，并且确信它们没有破坏任何东西，则可以在上一个程序集上开始整个测试周期。 但是，如果微软如此自信，认为这些更改不会破坏任何东西，那么它就不必在“寻求许可”阶段就扼杀它们。
Windows 10确实可以像可靠的机器一样工作如何正确做
我们发现与实际的敏捷项目有很大的不同。 例如，Google用于其广告投放服务器的开发过程。 这是公司基础架构的关键部分，但是公司的
新开发人员表示，他们进行了更改以消除一个小错误-更改已在白天投入生产。 将修订提交到资源库后，它将自动重建并进行一系列测试。 然后，此代码部分的维护者考虑更改，接受更改并将其与主要代码库组合，然后将其重新测试并在生产中部署。
当然，将其与Windows进行比较有点不公平：毕竟，当检测到错误时，云服务更容易回滚更改。 在系统启动时用蓝屏修改Windows更加难以撤消和还原。
但是，尽管如此，广告服务器还是一项至关重要的Google服务，最终该公司可以从中获利，而更新不成功很容易造成数百万美元的损失。但是自动测试和整个建立的过程甚至允许公司的实习生在几个小时内部署他们的变更，并放心地进行。发展思路根本不同。新功能在开发过程中可能会不稳定，但是将其添加到主分支后，必须符合较高的质量要求。微软的方法是“现在合并所有错误，我们将在以后修复它们”，并且在正确的过程中，在将新功能添加到主分支之前消除了错误。
Chrome , , —尽管云应用程序提供了一定的灵活性，但敏捷方法也适用于桌面软件。例如，谷歌对于Chrome具有类似的过程。 Chrome Beta版具有罕见的错误，但总的来说，其代码已接近发布质量。确实，Chrome开发的原则是，即使最新版本也应具有发行质量。您可以将Chrome的开发版本用作常规浏览器-仅通过图标即可了解这是一个Alpha版本，而不是稳定的渠道。这要归功于测试和检查的广泛自动化：在整个开发过程中，Chrome代码是高质量的，并且没有降低质量，并且我们在Windows中看到了后续的更改。为此，谷歌已投资基础设施。她拥有一个分布式构建系统，可以在1000个内核上并行构建Chrome，因此只需几分钟即可完成完整的构建。建立了有纪律的分支机构可以使合并变得容易且可预测。Google进行了广泛的功能和性能测试，以尽早发现错误和回归。所有这些都不是免费的，但是对于Google而言，以可持续的常规方式发布Chrome版本非常重要。Windows开发过程一直很糟糕
在新的开发过程中，Microsoft按比例分配了更多的时间来编写新功能，而花更少的时间来稳定和修复这些功能。如果功能质量从一开始就很高，并且在集成新代码之前具有测试基础结构和更高的标准，那么一切都会很好。但是到目前为止，使用Windows 10的经验是Microsoft尚未开发支持这种新方法所需的过程和系统。每年将发行数量从两个减少到一个的问题无法解决。在我看来，人们通常是通过粉红色眼镜观看Windows以前的开发的。但是，如果您回想起Windows 7和更早版本的时代，那么我们将看到非常相似的问题。然后通常的建议是在Service Pack 1发布之前不要升级到Windows的新版本。因为第一个发行版始终是令人无法接受的错误和不稳定-最好等到Service Pack 1解决其中的大多数问题。区别不在于开发Windows的新方法比以前差很多，或者不是旧方法产生了更好的结果。一点也不。
现在，我们看到了与之相同的事物，只是“等待Service Pack 1”这一时刻每年两次。每次进行新更新后，Microsoft都会相信该代码足以满足企业用户的需求-通常在初始版本发布后三到四个月。这是我们的“新” Service Pack1。因此，我们两全其美：从旧方法到开发Windows，有一些不良版本需要修复。采用新方法-每年发布两次，而不是每三年发布一次。因此，在一年中的大部分时间里，直到Service Pack发行之前的不稳定状况一直持续。主要缺点是通过集成未充分测试的函数来破坏代码库的稳定性，以期以后对其进行修复。这是一个糟糕的过程。在每三年发布一次Windows时，这很糟糕，而每六个月发布一次，则很糟糕。这不是内部人员的工作
第二个问题是测试的性质。 Microsoft过去拥有大量的测试人员，并且为每个功能分配了一定数量的开发人员和测试人员。他们中的许多人在2014年被解雇或转任其他职位。想法是将更多的测试职责分配给创建这些功能的开发人员。 Windows Insider程序还提供了大量的非正式测试-数以百万计的参与者（内部人员）。这远远超过任何以前的Windows beta程序。
不确定旧方法是否会检测到数据丢失错误。也许专业的测试人员不会测试删除数据的特定方案。但是很明显，微软没有处理内部人员发出的错误消息。在更新前三个月记录了数据丢失。许多错误消息的质量似乎很差，缺少必要的细节或正确的术语，但是如果公司三个月没有注意到问题，那么延长开发时间根本就不重要。较长的开发周期将意味着错误被忽略了六个月，而不是三个月。Microsoft承诺与内部人员一起更改反馈过程，以便他们指示问题的严重性，并引起人们对此类问题的更多关注。如果内部人员正确使用了严重性指标，这将有所帮助，但似乎不足以解决主要问题：质量过低的错误报告过多。这是指代码质量问题。 Insider的真正优势在于硬件和软件的多样性。内部人员可以识别出最奇特的兼容性错误，驱动程序问题，等等。但是内部人员不应进行基本功能测试。但是通常会有一种感觉，微软将它们用作全职测试人员。而且，如果代码质量在开发过程中下降，则预构建通常不适合普通PC上的日常使用。它们不够可靠。反过来，这破坏了内部人员进行测试的价值：内部人员没有将其安装在主PC上，也没有使组装过程中受到所有硬件和软件的影响。他们使用辅助PC和虚拟机。你必须投资你的工具
为像Windows这样的庞大项目开发类似Chrome的测试基础架构是一项非常艰巨的任务。尽管Windows的某些部分允许脱机测试，但其他部分只能在集成的集成系统上进行有效的测试。其中一些功能（例如OneDrive文件同步功能）甚至取决于外部网络服务的操作。这不是一件简单的任务。巨大的变化将是采用Windows代码应在每时每刻提供发行质量的原则-不是“经过数月的更正”，而是“现在，随时”。但这是必要条件。Microsoft必须解决从第一天起每个新更新都具有发布质量的情况。升级到最新版本的情况不成问题-此选择可以安全地接受。功能更新对用户应该是不可见的。将发行数量减少到每年一次或每三年发行一次将不会提供这种情况，也永远不会这样做。流程本身应该改变，而不是时间。