具体地讲，本文将讨论多个与如何管理版本有关的挑战，还将介绍为了提高生产力和质量而引入的一些变更。
在 14 个月的服务活动中，我与多个团队的成员合作过，不断增强现有流程，最大限度地提高开发团队的生产力，并满足客户为大型 Web 应用程序而设定的所有预期，这个 Web 应用程序是客户在竞争异常激烈的行业中取得全面成功的关键。该应用程序的实际用途对本讨论并不重要，我只想分享一下我在领导一个团队不断向业务关键型应用程序提供版本时学到的一些经验。
我的这个开发团队包括 7 位开发人员、1 位业务分析师、1 位部署经理和 1 位团队技术主管。快速了解一下每个角色可能会有所帮助：
业务分析师
生产支持团队收到的大部分通知单都是在现有代码中写入的缺陷，但在一些情况下，支持团队收到的通知单还需要更新业务规则。在这些情况下，业务分析师与业务团队（客户）合作创建一个需求文档，供技术主管和开发人员用于开发解决方案。
构建和发布经理
编写构建脚本并管理向测试和生产环境的部署。构建和发布经理也是所有构建工具的管理员，包括一个持续集成工具，监视所有与构建和部署相关的配置变更和日志。
开发人员
责任包括调查分析和修复分配给团队的通知单，执行同行评审，记录主要变更，以及依据流程在不同环境中验证代码修复结果。
团队/技术主管
管理所有版本，执行流程，并向开发人员分配通知单。主管担当开发人员与业务团队之间的联络人，确保所有日期和最后期限都得到满足和遵守。还在代码开发期间担当顾问，帮助做出架构决策。
测试团队
在发布到生产环境之前测试所有修复结果，确保新的代码基准的质量。
在我任职的初期，所有团队成员每周发布一个版本。我们的时间安排允许将任意数量的构建版本提供给测试服务器，但没有具体的最后期限。这些流程没有全面开发或执行，开发人员发现他们将时间浪费在了错误的任务上，或者过度承担了别人的任务职责，留给他们执行实际开发的时间很少。这种结构上的缺乏导致我们无法正确地、甚至大体地预测每个版本将完成的通知单数量，更糟的情况是，最后期限无法满足。由于不确定任何给定版本中将修复哪些通知单，测试团队没有足够的时间为提供给他们的通知单准备测试方案，最终可能无法在将新代码基准部署到生产环境之前全面测试它们。在许多情况下，最终结果是我们需要延迟一天或一星期发布一个版本，将它与后续版本一起发布；在一些情况下，新代码基准没有经过全面测试就发布到了生产环境中，导致客户开具了更多通知单。
为了克服这些（常见的）困难并成功地每周提供一个版本，我们需要明确地定义挑战和目标，努力修复现有流程，使我们能够遵守明确的开发周期。
重要的目标是：
提高生产力 提高质量 满足最后期限 满足客户的预期 渐进地完成这些增强，同时不中断每周的版本发布。
为了消除实现这些目标的阻碍，我们实施了一组战略行动，如以下各节所述。
行动 1：进行同行评审
在第一次试验中，我们保持每周发布时间表不变，这意味着我们要像以前一样每周发布一个新的代码基准。我们引入的第一个变更是向流程添加同行评审。
之前，开发人员没有执行过同行评审；他们要完成一次代码修复，在新版本分支中检查它，在开发服务器上测试它，然后让测试团队测试有无缺陷。引入同行评审，使我们能够提供更高的质量和更少的缺陷，最大限度减少开发周期的中断。
在一位开发人员完成一个通知单时，分配的一位同行会执行这个评审过程：
评审通知单和需求，确
保代码修复是完整的，并且解决了所有报告的问题。 评审代码更改，确保它在程序设计上是正确的。（我们研究了各种各样的同行评审指南，然后创建了自己的指南。） 评审文档（如果需要文档）。 在开发环境中运行并测试代码修复。
如果上述任何方面未通过测试，评审人员会将该通知单分配回开发人员，并提供注释。开发人员将继续完成这项任务，将它分配给同行人员进行评审，如此循环往复，直到通知单得到评审人员批准。最终将更高质量的代码提供给测试团队。
行动 2：修改时间安排
下一个更改是创建一个新的时间安排供所有团队遵守，然后执行它。我们还将发送给测试服务器的构建版本数量限制为 2 个。
图 1 显示了每周一个版本的时间安排示例。
在这个时间安排中，第一列描述了不同的任务。第二列列出了将负责该任务的小组。剩余列表示该版本所在星期的每一天。
我们看看该时间安排中涉及的每个任务：
代码稳定化和提交给同行评审
开发人员必须完成所有代码开发，确保所有代码都已在开发环境中签入、部署并测试。他们然后将通知单转交给同行进行评审。
代码签入最后期限和同行评审结束
在同行评审期间，评审人员将通知单发回给开发人员，以修复找到的所有问题。开发人员和评审人员应在这个最后期限内完成这个周期，准备好并最终确定通知单。
代码合并
在以前和当前的版本之间执行代码合并。
部署到测试环境
构建和发布经理将新代码基准部署到测试环境，完成之后通知开发人员。
开发人员验证
开发人员在测试服务器上执行验证，确认所有这些代码修复已正确部署并在服务器上按预期运行。如果发现任何数据或配置错误，他们会修复并记录问题，确保在生产服务器上发生该问题会正确处理它。
测试
测试团队开始测试。
所有团队签字
举行最终决定电话会议，开发、构建和部署、业务及测试团队至少派一位代表参加，其他任何相关的客户人员也可参加。这是一个版本的生命周期中的最后一次会议。现在，所有团队都将清除部署生产环境中的版本，释放测试环境供下一个版本使用。如果在此版本中有任何问题或担忧尚未解决，那么他们会在会议中提出这些问题，并制定一个行动计划来解决这些问题。如果发生任何延迟，在条件允许的情况下，可将版本延后发布。
生产部署
构建和发布经理向生产服务器发布代码基准。
现在我们看看时间安排：
在上面 10.21.0 版的示例中，开发团队第一个随后期限是 12 月 5 日下午 1:00，稳定代码并提交给同行人员评审。实际的代码签入最后期限是在 12 月 5 日下午 5:00 点。这为开发人员提供了 4 小时来执行同行评审并修复找到的所有问题。 在星期五早上，构建和发布经理会将代码部署到测试环境中，然后通知执行验证的开发人员。 下午 1:00，测试团队将执行测试，直到当天结束。 第二次构建始于 12 月 9 日，类似该周期的第一部分：开发团队将解决测试团队列出的所有缺陷，执行同行评审，然后在当天结束时签入代码。 12 月 10 日，新代码将部署到测试服务器，测试人员将确认所有缺陷都已修复。 12 月 11 日，测试团队将继续测试，直到
举行最终决定电话会议。
从此时间安排可以看到，如果返回到 10.20.0，如果开发人员的第一个构建版本没有任何缺陷，那么他可在 11 月 29 日完成验证步骤后立即开发下一个版本。这为开发人员提供了每个版本最长 36 个小时的开发时间。如果他需要解决缺陷，这意味着他有大约 24 小时的开发时间。对于列出的缺陷，团队将始终优先解决 10.20.0 版本的缺陷，而不是 10.21.0 版本；解决完缺陷后，他们会继续开发 10.21.0 版本。
实施新时间安排后，各个版本都非常小，每个版本平均修复并完成 4 个通知单（一些通知单需要超过 36 小时的开发时间，意味着不是所有开发人员都会参与每个版本的开发）。这与前几个月的数字是一致的。但是，区别是我们最终能够稳定该流程 — 而且在团队开始遵循该流程时，版本的质量得到了改进。
此刻的抱怨主要来自测试团队，因为他们没有足够的时间来测试，还有一些开发人员，他们必须在同行评审后在一个通知单上返工。另一方面，业务合作伙伴非常高兴我们能够向一个版本的每个日期分配通知单并按时解决它们，但他们可能对生产力感到不满意，因为他们希望每周解决更多的通知单。
公平地讲，这个时间表没有过多地考虑任何外部问题，比如服务器故障和其他系统问题。考虑到紧张的时间表，这些类型的问题常常影响到可交付结果和发布日期，有时导致发布一个仅有两处修复的版本，或者延后一个版本并将它与后续版本合并。
随着我们对此方法的进一步了解，我们对比了优缺点并与所有各方进行了协商，开发了两种新的不同的时间安排，为利益相关者提供不同的选择：
选项 1：第一个替代方案是将团队拆分为两个，以便每个更小的团队每两周处理一个版本。这在部署到生产环境之前，为每个团队提供了时间来开发他们的版本并提供支持。该方案还遵守了之前的每周一个版本的时间表。 选项 2：第二个替代方案是保持该团队为单个团队，但将版本发布时间表更改为双周（每两周一个版本）。
如果查看选项 1 的时间安排，可以看到两个版本之间存在一定的重叠。尽管涉及的资源不同，但此方法需要管理两个团队，他们同时处理其版本的不同阶段。而且，一些通知单将需要比分配的更多的开发时间，促使开发人员处理与最初分配不同的版本，导致团队规模（进而导致输出）不平衡。
图 2 给出了一个包含两个替代团队，一周发布一个版本的时间安排示例。
图 2. 每周一个版本，两个团队
执行以下计划：
团队 A 处理版本 10.20.0 和 10.22.0，同时团队 B 处理版本 10.21.0。 团队 A 将在 11 月 28 日中午完成版本 10.20.0 的处理，同时开始处理版本 10.22.0。 每个版本的开发时间从 6.5 到 9.5 天不等，具体时间取决于是否存在缺陷。 对于 10.22.0，团队的第一个最后期限是，他们需要在 12 月 10 日提交代码修复，以便进行同行评审。此时，所有代码修复都应签入 10.22.0 版本分支中，由开发人员部署到开发环境并进行验证。 我们还需要将 10.21.0 版本合并到 10.22.0 版本基准中。这将在批准 10.21.0 版本发布到生产环境中后完成。 12 月 12 日，构建和发布经理将 10.22.0 基准部署到测试环境，然后开发人员将执行验证，测试人员随后将开始测试。
在新时间安排中，测试人员有大约两天的测试时间。所有通知单的所有测试都应在 12 月 12 日结束之前执行和完成，回归测试（如果需要）将在 12 月 13 日执行。开发团队将在写入缺陷后立即处理它们，确保它们满足第二个构建最后期限，也就是 12 月 16 日。向测试环境的第二次构建和部署将在 12 月 17 日执行，随后开发人员验证并向测试团队释放该环境。
请注意，在团队 B 执行 10.21.0 版本的开发的同一周，团队 A 将最终确定 10.20.0 版本，执行同行评审和开发人员验证，确保所有列出的缺陷都已在 10.20.0 的第二次构建中按时修复。如果没有向团队 A 分配 10.20.0 版的缺陷，他们可开始开发 10.22.0。另请注意，在 12 月 5 日之前，开发环境将由团队 B 用于开发 10.21.0，所以团队 A 将需要在 12 月 5 日之前在本地开发代码。
选项 2 更进了一步，通过捆绑通知单并删除以前的模型中的一些开销，提高了生产力。在此模型中，我们将把一个团队拆分为两个。我们将拥有更少的测试服务器部署（这可能让所有团队中断工作），而且代码合并量极少。
图 3 给出了一个两周一个版本，包含单个团队的时间安排示例。
图 3. 两周一个版本，一个团队的时间安排
表 1 给出了所有 3 种版本时间安排之间的对比结果。
表 1. 开发版本时间安排对比
项目元素 每周一个版本（最初） 每周一个版本，包含替代团队 两周一个版本 开发时间（天） 3 到 4.5 6.5 到 9.5 6.5 到 9.5 开发人员验证（小时） 4 4 4 同行评审（小时） 10 13 21 测试（小时） 10.5 18.5 26
在有一个重要的通知单无法等到计划的版本发布时，我们仍会为我们未计划发布版本的一周维护一种时间安排。这可向不同的合作伙伴保证，我们能够仍然根据需要处理未计划的版本，充当一个 “安全网络”；我们能够按这些日期发布版本而不影响计划的版本。例如，如果我们需要激活一个未计划版本的时间安排来修复一个缺陷，那么只需一位开发人员来处理它即可，构建、部署和测试工作极少，这使得我们能够集中精力处理主要的两周版本。
图 4 显示了一种需要计划外的例外版本的情况。
图 4. 例外版本的时间安排
可以理解，开发人团队最喜欢第二种两周版本的选项，但不容易让其他一些团队同意。最终，此方法的优点多于缺点，我们能够说服合作伙伴采用新计划，让我们每两周发布一个版本。采用第二个时间安排选项后，我们能够最大化版本周期，给同行评审和测试留出更多的时间。
得益于这个新的版本时间安排，按完成的通知单数量和每季度的开发小时数算，团队的生产力提高了近 100%。团队每两周平均处理 16 个通知单，而最初每周仅处理 4 个通知单。
行动：3 细化服务水平协议
除了定义时间安排和版本周期长度，我们还需要定义（并执行）成功的版本的必要条件：
向一个版本提交通知单的最后期限
我们在服务水平协议 (SLA) 中添加了一条新内容，规定将通知单提交到计划的版本内的最后期限是第一个构建代码冻结前的 6 个工作日（排除需要立即关注的很重要的通知单）。这还意味着通知单已准备好开发；例如，如果需要使用需求文档，该工作应该已经完成。
需要同行评审
通过要求同行评审，包括评审代码，确保修复完成，并确认问题已得到解决，而且修复结果已经过测试，我们可确保更高的质量和更少的缺陷。（这一步将每个版本列出的缺陷数量减少了一半以上，可确保开发人员在完成当前版本后，立即就能自信地开始开发下一个版本）。
每个版本周期内向测试环境部署的构建版本数量
最初，我们允许使用无限多个构建版本，该数量取决于每天可解决的通知单数量和每天列出的缺陷数量。在一些两周版本中，我们可能每天创建一个构建版本，在生产发布之前的最后一天创建的构建版本可能更多。我们决定将此限制为每个版本周期两个构建版本。SLA 现在规定，分配给一个版本的所有通知单都需要准备好在向测试服务器提供第一个构建版本中进行测试。
测试团队需要遵守时间安排，在分配的时间范围内完成所有通知单的测试，在找到缺陷后立即列出它们，然后将它们分配给开发人员，开发人员随后会解决这些缺陷，以便在提供给测试环境的第二个构建版本中修复它们。测试团队下次的测试时间更短，但他们仅需验证为第一个构建版本列出的缺陷的修复结果。
测试
测试团队现在有更多时间在测试环境中工作，他们之前需要处理的由多个构建版本和部署所导致的中断很少。自现在定义该周期后，他们还能够更好地管理他们的资源。
他们会在开始处理该版本之前 7 个工作日准确了解该版本中的通知单列表，为他们提供足够的时间来准备测试案例和方案，从而确保提供更高质量的可交付结果。
在未满足最后期限时采取的行动
当然，有时预计的工作水平不准确，导致未满足最后期限。SLA 定义了 3 个处理此情形的选项：
如果需要的外开发时间不到半天，我们会将整个时间安排延长半天，以便为完成开发提供时间。 如果需要的额外开发时间超过半天，我们会回滚更改并将通知单转移到下一个版本。 在非常特殊的情况下，在通知单必须在当前分配的版本中修复时，我们允许在第二个构建版本的最后期限之前准备好该通知单，分配额外的同行评审时间，并提前通知测试团队，以确保有足够的资源可用于按时完成测试。 在第二次构建后有缺陷时采取的行动：
在很少的情况下，我们可能面临着在第二次构建后列出了新缺陷的情形。在这种情况下，我们有两个选项：
如果该缺陷导致比最初报告的更多的问题，或者如果业务合作伙伴将它视为很高的风险，我们会回滚与导致该缺陷的通知单相关的所有代码，并在下一个版本中解决它。这样，就为开发人员提供了足够的时间来完全修复问题。在这种情况下，开发人员将回滚代码更改，还需要向测试服务器提供第三个构建版本。测试团队随后会重新进行测试，确保基准已返回到之前的状态。 部署包含该已知缺陷的当前版本并在下一个版本中修复该缺陷 — 或者如果它至关重要，可作为一次应急修复，只要准备就绪了。
决策主要基于该缺陷的新修复结果与最初的通知单相比是否具有更多的不足。如果是，我们会从该版本中删除它。如果不是，我们会部署这个已知缺陷的修复结果，并在下一个版本中部署另一个修复结果。
行动 4：管理版本控制
很少有事情像版本控制对软件开发项目那么重要，尤其是在项目在项目规模、团队规模和可视性等所有元素上都被放大时。
分支和合并
每次团队开始处理一个版本，该流程就会要求从代码中创建一个新分支。开发人员被要求跟踪所有分支并将其代码签入到所有开放的分支中。我们更改了该流程，以便从最新的生产支持开放分支创建分支，而且开发人员只需将其代码签入到他们正在处理的版本中，这减少了不断跟踪多个分支的开销。在两种情况下，我们需要与向生产环境的最新部署执行一次合并。
该合并将由一位开发人员在一次循环后执行。给定两周一个版本的时间表，基于何时创建分支和我们是否有第二个构建版本，您可以在时间表上看到合并可能不是必需的或作用很小。
管理可用的环境
最初设置是，每个版本都要经历 3 个不同的环境（服务器），才会部署到生产环境中：
开发：开发人员在其本地环境中完成开发和测试后，使用此环境测试他们的代码。开发人员拥有服务器的完整访问权，可使用一个构建工具部署该代码。这里不需要版本经理。所有开发人员都使用他们的本地设置来执行开发工作，完成之后，使用开发环境来执行测试和同行评审。 稳定：此环境设置为测试环境的完全相同的副本，而测试环境应是生产环境的完全相同的副本。版本经理将执行构建来测试他的脚本。开发人员验证所有签入的代码和配置是否已成功部署。如果有任何问题，开发人员会努力修复它，版本经理记下笔记，确保向测试环境（以及然后向生产环境）的部署是完整的。 测试：版本经理将代码基准部署到这个环境中，然后测试团队运行他们的测试脚本，确保代码基准已为生产发布做好准备。
我们做了一项更改，以便提供更多开发和测试时间，并减少环境相关缺陷，这项更改那就直接跳到第二步。我们部署到测试环境，允许开发人员和版本经理验证构建版本是否已成功，然后将该环境转交给测试团队。
我们前一个模型的主要问题是，在许多情况下，稳定环境不是测试环境的完全相同的副本，所以我们最终存在与环境相关的问题；也就是说，一个问题会在一个环境中出现，在另一个环境中却不会出现。例如，开发人员将在稳定环境中验证他们的代码，然后传递给下一个环境。然后，如果测试环境中的数据或配置存在问题，测试人员可能会列出针对不一定与代码相关的问题的缺陷。
现在，因为开发人员在测试环境中进行了验证，所以我们可确定他们转交的环境没有数据或部署问题，使测试人员能够仅处理版本缺陷，而不处理与环境相关的缺陷。
稳定环境仍在使用，但作为一个开发环境，供开发人员测试第一个构建版本中列出的缺陷的修复结果，以便为第二个构建版本做好准备。
版本 ID
我们执行了一项细微更改，将版本 ID 从日期更改为版本编号。这影响到了我们使用的分支和通知单队列中分配的版本 ID。采用这种简单的命名约定，我们不再需要经历在版本日期更改时更新所有引用的过程。
结束语
本文重点介绍了我作为一个生产支持团队的主管所总结的一些经验，该团队负责一个维护商业企业的 Web 应用程序。尽管这个实际项目很大，而且持续时间较长，但这里描述的许多挑战在所有规模的项目中都存在。类似地，在寻找提高您自己开发项目的质量和满足您承诺的方法时，执行的解决方案（包括用来管理资源、设置时间安排、评审和更改流程、重新建立 SLA 等的方法）可能也适用 — 或者至少值得讨论。
