照顾您的持续集成系统

我在团队中的角色之一是构建人员。我负责维护/更新我们的构建脚本，并确保我们在连续集成服务器上“顺利”构建。我通常不介意这份工作，尽管经常感觉好像我一直在保姆CI服务器。

该工作有时会很烦人，因为如果构建中断，我必须放弃我正在研究的故事并调查构建失败。建设失败每天都在我们的团队中发生。有时，开发人员只是在提交之前未在本地进行构建，因此测试在CI服务器上失败。在这种情况下，我想快速联系遇到“错误提交”的人，以使构建不会太长时间损坏。有时（不那么频繁）在CI服务器上存在需要调试的奇怪情况。

我知道许多成熟的团队都使用持续集成，但是关于良好实践的材料并不多。

我的问题是否指出我们的持续集成还不是很成熟，或者这仅仅是工作的一部分？

要遵循哪些良好做法？成熟的持续整合的特点是什么？

更新资料

除了回答一些评论外，我将进行更新。我们有一个简单的命令，它完全可以执行构建应用程序时构建服务器的操作。它将编译，运行所有单元/集成以及一些基于UI的快速测试。

阅读每个人的答案，感觉我们可能有两个主要问题。

1. 当构建失败时，CI Server不会抱怨得太大声。
2. 开发人员并不觉得确保自己的提交成功完成是每个人的责任。

使我的团队变得更困难的是，我们有一个庞大的团队（超过10个开发人员），并且有几个离岸团队成员甚至在不上班的时候都会投入工作。因为团队规模很大，并且我们确定经常进行小型提交是首选，所以有时我们一天中确实有很多活动。

首先，每个人都要负责构建过程。听起来您团队中的成员还不成熟...没有人愿意编写代码并将其散布到CI服务器，以希望它能正常工作。在提交代码之前，应在其本地计算机上对其进行测试。您应该确保要检查的代码不会破坏构建。当然，在某些情况下，构建会无意间中断（例如，如果更改了配置文件或无意中提交了草率的提交）。

大多数CI服务器（我只使用过Hudson）都会发送一封自动电子邮件，详细说明导致构建中断的提交。您角色的唯一组成部分是站在他们后面，看起来很强硬，直到嫌疑犯修复他们所破坏的一切。

您的团队弄错了一件事：

负责构建服务器与负责构建不同。

签入代码的人员有责任使其“起作用”（为了获得一定的作用价值）。拥有构建服务器的唯一原因是在此过程中需要监督。任何值得一试的构建服务器都可以通过以下信息通知自上次构建以来签入代码的人员（以及其他感兴趣的人）：

• 建立失败了！
• 构建时出了什么问题！
• 自上次构建以来发生了什么变化！

这经常通过电子邮件发生。重要的是，此操作在每次入住后都必须尽快完成。

然后，该人员可以查看出了什么问题并进行修复，然后构建服务器会通知感兴趣的任何人该构建已恢复正常。除登机原因外，这应独自发生，而无需其他任何参与。

因此，要回答你的问题：一个成熟的CI环境里不要求看门人在其正常工作的参与。

另外，如果“奇怪的条件存在”非常频繁地发生，则找出原因，使系统更强大。

更改过程。如果提交破坏了构建，请自动回滚该提交，并通知破坏它的开发人员。允许一个团队成员出错会减慢团队其他成员的速度是很愚蠢的。或者让开发人员签出集成机，而不是自动完成集成构建，如果构建成功，则可以提交。持续集成并不意味着“检入您喜欢的任何垃圾，然后有人会为您修复它”。

除非为黄金分支配备了网守，否则“黄金分支”策略将不起作用。

像Git这样的DVCS可能会有所帮助；开发人员可以只提交一个变更集以集成到CI服务器，而不用提交，然后服务器可以尝试集成变更集。如果集成成功，那么变更集将被合并，否则将被拒绝。

我经常看到的一个问题是，开发人员无法执行与 CI构建步骤完全相同的本地构建。也就是说，CI服务器配置为包括无法在本地执行的额外步骤，例如单元/集成测试，覆盖范围等。不可避免地，开发人员会被无法在本地执行的步骤之一所困扰，并开始质疑为什么他们在办理登机手续之前根本不愿意在本地构建发行版。

我将整个构建保持独立，并让CI服务器简单地启动发布构建，而没有定义任何多余的配置/步骤。开发人员可以运行一个发布版本本地前检查，其中包括所有将被CI构建进行并更加自信，当他们什么都不会打破的步骤做办理登机手续。

这种方法的其他好处包括：

• 在CI服务器之间切换很容易，因为您没有花费大量时间配置无关的步骤
• 所有构建时工具都在源代码控制下，这意味着所有开发人员都使用完全相同的工具集来构建系统
• 除了上述要点之外，还很容易以受控方式更改构建工具

PS。整个构建保姆的概念是荒谬的，但是其他人已经涵盖了这一点。

首先，开发人员不应定期破坏构建-在提交给CI分支之前，他们应该在本地构建和运行测试。中断构建应该是一个耻辱，强制执行这一点很重要。我已经通过发布统计信息来做到这一点，并且我已经看到其他团队有一个“构建包”，每次您破坏构建时，您都会投入一美元。在项目结束时，钱用于啤酒。

如果羞耻/个人自豪感不起作用，则您可能不得不转向更重的东西（例如威胁解雇）。在出发前破坏建筑应该是主要的罪行。每个开发人员都应该在其桌面上收到构建状态通知。所有这些最好的部分是它鼓励较小的提交，无论如何，它们都是首选。

也就是说，构建有时会中断（例如，CI配置原因）。有时，人们会搞砸了，离开了整日的一天。这就是为什么您应该针对允许快速轻松地回滚到已知良好版本的过程的原因。如果您总是可以回滚到上一个良好的版本（并将回滚的版本部署到所有必要的位置），那么在最坏的情况下，如果构建版本已损坏，罪魁祸首已在当晚离开，则可以滚动回到最后一个好的版本，并在早上对他/她大喊。

我不能推荐足够的连续交付书。如果您正在寻找有关如何完善配置流程的指南，请尝试一下。

我听说微软（也许是？）做了一件事情，那就是让保姆在团队中移动。他们这样做的方式是，当有人破坏构建（可能应该包括检入未通过测试的内容）时，他们将扮演角色。这使人们以非常直接的方式对自己的行为后果负责。考虑到这是一项令人讨厌的工作，它鼓励他们不要再次破坏构建。

当前负责构建的人员可能有特殊的帽子。可能要举行交接仪式。

请注意，正如Thorbjørn所说，负责构建与负责构建服务器并不相同。服务器的责任可以永久地由一个或多个基础设施倾斜的团队成员承担，而构建的责任则随处可见。

现在，除了流程的细节之外，我将和一群人一起对开发人员在不运行构建和测试的情况下签入表示沮丧。不能接受！

如果您的团队中有一些成员更可能破坏构建（并且根据我自己的经验，我主要是在考虑其他国家的成员），并且您正在使用一些不错的现代源代码控制，例如Mercurial或Git，您可以让他们签入团队其他成员的不同分支，在该分支上运行单独的CI流程，并在成功构建后自动将该分支中的更改合并到主干中（请注意，您必须在合并后运行第二个构建并进行测试，然后再检查合并！）。由于自动合并并不总是成功，因此最终将使分支需要人工关注，但这可能是真正的麻烦。不过，与为团队其他成员签入破损的代码相比，它可能会更轻松。

正如Jonathan Khoo所说，你们都应该负责构建服务器和构建脚本。有以下三个原因：

1. 目前，您遇到的情况是“ 1的总线”，这意味着如果您被总线冲了过来，则会丢失构建服务器和构建脚本的全部知识。
2. 您（正确或错误）编写的脚本只有输入内容。就像任何代码一样，参与其中的人员越多，可以应用到它的知识库就越广。
3. 最后，当出现问题时，只有您感到痛苦。痛苦是一件好事，但孤立时却不是。目前，您正在处理痛苦，但是如果其他所有人都在痛苦，那么您会发现他们最终将在提交代码之前更加严格地测试代码。

我本人非常喜欢CI，因此陷入了维护脚本的陷阱，但是您可以采取一些措施来减轻这种情况。

1. 构建脚本不仅应在CI服务器上运行，而且还应在本地开发计算机上运行。它们应该产生相同的输出，运行相同的测试，并且由于相同的原因而失败。这使开发人员可以在提交代码之前运行脚本。
2. 如果有人确实破坏了版本，则通过使用任务栏弹出窗口，电子邮件，闪光灯，噪音等将其公开。它不仅使团队成员感到尴尬，而且还为团队中的其他每个人提供了一个跳起并助攻。
3. 暂时避免修复构建。让别人去做。如果没有其他人跳起来，请等待坏事情发生，并将其用作整个团队的学习点，以了解CI服务器为何如此重要。
4. 尝试使构建服务器和开发计算机尽可能不安装任何第三方组件，尤其要保持GAC清洁。依赖于位于项目库文件夹中的第三方组件。这有助于更快地识别丢失的组件。

可见性将帮助您。所有团队成员都需要知道他们应该解决一个活跃的问题。电子邮件通知很有用，但是如果开发人员很忙并且不立即对其进行响应，则他可能会忘记它，并且电子邮件最终会变成大量通知。

您可以尝试使用Catlight或BuildNotify之类的工具。它们显示托盘区域中重要建筑物的当前状态。每次开发人员看时钟时，他都会看到有一个损坏的版本需要修复。

Catlight还将显示谁首先破坏了构建，这给这个人带来了社会压力，因为整个团队将在每次连续的构建失败中看到它。

一种策略是对许多小型项目使用大量的小型分支机构。然后，当有人破坏构建时，他们只是为自己破坏构建。因此，他们会从构建服务器获取恼人的电子邮件，这取决于他们是否担心。

另一个是提高人们的责任感。例如，如果您使用Rietveld之类的东西，那么人们将无法通过同行评审来做出承诺。（实际上，该过程比您想象的要轻得多。但是，它确实迫使人们“流水线”并同时处理多个事情。）保存构建是提交者和审阅者的责任。如果有人定期破坏构建或批准破坏构建的事情，那么不要让他们对提交进行最终批准。与任何人都可以轻松回滚任何更改的过程相结合，并且构建不会像通常那样中断，并且一旦更改就不会中断。

我将在这里与大家讨论一下，说实际上，偶尔中断构建并不是一件坏事，因为这表明实际工作正在完成。是的，开发人员应在提交之前进行构建和测试，但是测试的主要负担应由开发自动化工具（包括持续集成服务器）承担。可以使用这些工具，除非构建一次又一次中断，否则不清楚您是否会尽力而为。不过，我确实认为，该版本永远都不应在任何长时间内都被破坏，并且如果它有助于支持集中式自动化测试设施快速反馈的双重目标，那么它甚至会支持自动回滚或多阶段提交过程，再加上一个“绿色”树干。

请记住以下几点：

1. 您的团队需要遵循一系列标准
2. 您需要掌握干净代码的想法，并努力改进代码实践。
3. 测试测试测试！签入之前，请务必进行测试。
4. 尽管我确实同意中断构建是可以的，但这是一种罕见的情况，我的意思是极其罕见的情况可以接受。如果这是每天的活动，我会找门或者与老板谈谈标准。

总体而言，你们需要制定，基于最佳实践而不是个别实践制定标准（显然，这些实践没有奏效）。一旦所有人都同意标准，就可以开始代码审查过程并执行标准。听起来好像管理层去度假了，再也没有回来。老实说，这些对于任何商店都是非常基本的。好的代码的基础始于好的标准，该标准指示团队代码及其编写方式。只是我的想法。最近，我在新工作中遇到了类似情况，并与老板交谈。向他解释，我们需要完成XYZ，因为它会影响ABC。两周后，我编写了要遵循的代码标准列表并进行了介绍。在我的同事们提供意见之后，大约两个月后，我们制定了解决大量问题的标准。