6

我想每个人都同意持续构建和持续集成有利于软件产品的质量。及早发现缺陷，以便尽快修复。对于需要几分钟的连续构建，通常很容易找到导致缺陷的人。但是，对于需要很长时间运行的夜间集成测试，这可能是一个挑战。以下是具体情况，我正在寻找最佳解决方案：

  • 运行集成测试需要 1 个多小时。因此，它们在一夜之间运行。每天都会发生多次签到（大约 15 名开发人员的团队），因此有时很难找到“罪魁祸首”（如果有的话）。
  • 集成测试环境依赖于其他环境（Web 服务和数据库），这些环境可能会不时出现故障。这会导致集成测试失败。

那么如何组织团队，让这些故障早日解决呢？在我看来，应该指定一个人来诊断缺陷。这应该是早上的第一个任务。如果他需要其他人的专业知识，他们应该随时可用。一旦确定了故障的来源（组件、数据库、Web 服务），所有者应该开始修复它（或者应该通知另一个团队）。

如何任命诊断缺陷的人？理想情况下，有人会自愿（哈哈）。恐怕这种情况不会经常发生。我听说过其他选择——首先到办公室的人应该检查每晚构建的结果。没关系，如果整个团队都同意的话。但是，这会奖励那些迟到的人。我想这个角色应该在团队中轮换。不应接受“我对构建了解不多”的借口。故障源的诊断应该相当简单。如果不是，那么在代码中添加更多的诊断日志记录应该可以提高对集成测试失败的可见性。

在这方面的任何经验或改进上述方法的建议？

4

7 回答 7

6

微软关于破坏夜间构建的著名政策是，提交破坏构建的人将负责维护夜间构建，直到其他人破坏它。

这是有道理的，因为

  • 每个人都会犯错，因此会发生必要的轮换（在模棱两可的情况下使用最近最少使用的选择模式）
  • 它鼓励人们编写更好的代码
于 2009-12-22T15:16:18.087 回答
3

我通常做的（我为一个 8 到 10 人的团队做过）是两个有一个人检查构建，这是他早上做的第一件事——有人会说他负责 QA，我想。

如果有问题，他有责任找出什么/如何——当然，如果需要，他可以向团队的其他成员寻求帮助。

这意味着团队中至少有一名成员必须对整个应用程序有很好的了解——但这无论如何都不是一件坏事：它会在应用程序在生产中使用并出现故障的那一天帮助诊断问题。

而不是让一个人来做那件事，我喜欢有两个人：一个人一周，另一个人第二周——例如；这样一来，即使其中一个人在假期，总是有可以诊断问题的人的机会更大。


作为旁注：您在构建过程中记录的有用的东西越多，就越容易找出问题所在——以及为什么。


为什么不让团队中的每个人每天早上检查构建？

  • 好吧，首先，不是每个人都想这样做——如果这样做的人喜欢他所做的事情，那将会做得更好
  • 而且你不希望 10 个人每天花半个小时在上面 ^^
于 2009-12-22T15:07:32.463 回答
2

在您的情况下，我建议负责 CM 的人。如果是负责太多职责的经理或技术负责人，为什么不把它交给初级开发人员呢？我希望有人在我职业生涯的早期强迫我更彻底地了解源代码控制。不仅如此，查看其他人的代码以找出错误来源也是一项真正的技能培养或知识学习练习。他们说你从查看其他人的代码中获益最多，我坚信这一点。

于 2009-12-22T15:11:11.640 回答
1

有经验与无经验的配对

您可能需要考虑让一对开发人员诊断损坏的构建。我很幸运。特别是如果您将对构建系统不太熟悉的团队成员与非常熟悉的团队成员配对。这可能会减少团队成员说“我对构建不太了解”作为试图摆脱职责的方式的可能性，并且会减少您的公共汽车数量并增加集体所有权。


让团队选择您指定的解决方案或他们自己制定的解决方案

您可以将问题提交给您的团队并要求他们提供解决方案。告诉他们，如果他们没有提出可行的解决方案，您将制定每周计划，每天分配一对，并确保每个人都有机会参与。

于 2010-01-11T18:22:34.943 回答
1
  • 练习持续集成，这样您就不需要不频繁的大型构建 **如果一台机器执行速度太慢，您可以在机器之间分发构建
  • 使用构建状态监视器，这样任何签入的人都可以对构建失败负责。
  • 有一个下午的入住截止日期

任何一个：

  • 下午 5 点后无人签到

或者

  • 没有人会在下午 5 点之后签到，除非他们准备好继续工作，直到他们的构建通过绿色 - 即使这意味着工作、提交修复并等待重建。

执行和遵守第一种形式要容易得多，所以这就是我要遵循的。

我的一个前团队的成员实际上接到了电话，并被告知要回去工作以修复构建……他们做到了。

于 2010-01-14T12:15:59.400 回答
0

我很想建议以两种方式中的任何一种来拆分：

  • 时间分割 - 假设测试可以每晚运行两次，为什么不在 2 个不同的时间点对代码运行测试，即所有签到到下午 X 点，然后是其余时间，这样可以帮助缩小范围问题是。

  • 团队拆分 - 代码是否可以拆分成更小的部分，以便可以在不同的机器上运行测试，以帮助缩小应该深入研究的团队？

这假设您可以多次运行测试并以这种方式划分事物，因此这是一个粗略的想法。

于 2009-12-22T15:16:57.530 回答
0

每天早上，在开始工作之前，我们都会举行一次站立会议。清单上的一件事是每晚构建的状态。我们的构建系统在运行后会发送一封电子邮件，报告状态，因此很容易找到 - 碰巧，它发给了一个人，但实际上它应该发给每个人，或者发布到项目 wiki 上。

如果构建被破坏，那么修复它就成为最优先的任务，像任何其他任务一样处理，这意味着我们将在站立会议上决定谁来处理它，然后他们去做。我们进行结对编程，通常会将其视为结对任务。如果我们人手不足，我们可能会指派一个人来调查破损，然后再与他配对，稍后再修复它。

我们没有正式的任务分配机制：我们是一个小团队（通常是六个人），并且拥有集体代码所有权，所以我们只是在自己之间解决。如果我们认为某一对的签入破坏了构建，通常是他们来修复它。如果不是，那可能是任何人；这通常是通过查看谁目前没有在执行其他任务来决定的。

于 2010-01-14T18:28:10.280 回答