The following text is a partial translation of the original English article, performed by ChatGPT (gpt-3.5-turbo) and this Jekyll plugin:
几天前，我的文章《为什么持续集成不起作用》在DevOps.com上发表。几乎在同一天，我在Twitter上收到了几条非常负面的评论。
以下是我对未被提问的问题的回应：
即使我在这个领域有一些经验，我不会将其作为一个论据。相反，我会尽量只依赖逻辑。
顺便说一下，我的经验包括在50多个开源和商业项目中使用Apache Continuum、Hudson、CruiseControl和Jenkins五年之久。除此之外，几年前我创建了一个名为fazend.com的托管持续集成服务，2013年改名为rultor.com。目前，我也是Travis和AppVeyor的活跃用户。
这个想法很简单明了。每当你在master分支（或在Subversion中的/trunk）上进行新的提交时，持续集成服务器（或服务）会尝试构建整个产品。构建包括编译、单元测试、集成测试、质量分析等等。
结果要么是“成功”，要么是“失败”。如果是成功的，我们说“构建成功”。如果是失败的，我们说“构建失败”。构建通常会因为有人提交了新的代码，导致之前通过的单元测试变为失败。
这是问题的技术方面。它总是有效的。嗯，它可能会有一些问题，比如硬编码的依赖、环境之间缺乏隔离或并行构建冲突，但本文不涉及这些问题。如果应用程序编写良好且其单元测试稳定，持续集成就很容易。从技术上讲。
现在来看看组织方面。
持续集成不仅仅是一个构建服务器，还是一个应该“工作”的管理/组织过程。所谓“工作”的过程，正如Jez Humble在《持续交付：通过构建、测试和部署自动化实现可靠软件发布》（购买链接）第55页所说的那样。
这是不起作用且无法起作用的。
正如我们所看到的，持续集成是将整个开发团队暂停并修复破损的构建。让我再强调一下。一旦构建破损，每个人都应专注于修复它并提交一个将构建恢复到稳定状态的提交。
现在，我的问题是，在一个活跃的工作团队中，可能需要这个吗？
是产品负责人，他们希望尽快将新功能推向市场吗？或者是项目经理，他们负责项目的截止日期？或者是程序员，他们讨厌在压力下修复别人制造的错误吗？
谁喜欢这种持续集成，谁需要它？
What Happens In Reality?
我可以告诉你，我已经看到了很多次了。情景总是一样的。我们只是开始忽略那个持续集成构建的状态。无论构建是干净的还是破损的，我们都会继续做我们之前在做的事情。
我们没有停下来修复它，就像Jez Humble建议的那样。
相反，我们忽略了来自持续集成服务器的信息。
最终，也许明天或者星期一，我们会尽量找一些空闲时间来修复构建。只是因为我们不喜欢仪表盘上的红色按钮，想要将其变成绿色的。
是的，这个问题还有另一面。我们可以试着在团队中强制执行纪律。我们可以制定一个严格的规定，也就是我们的构建始终是干净的，任何犯规的人都会受到某种惩罚。
试着这样做，你会得到一种叫做恐惧驱动开发的结果。程序员会害怕将任何东西提交到代码库，因为他们知道如果导致构建失败，他们将不得不道歉，至少要道歉。
在这种情况下，严格的纪律（我是一个大支持者）只会使情况变得更糟。整个开发过程变慢，程序员会尽可能将他们的代码保留给自己，以避免可能的构建错误。当到了提交的时候，他们的改动非常大，合并变得非常困难，有时甚至是不可能的。
结果，你会得到很多一次性的代码，由某人编写但从未提交到master，都是由于这种恐惧因素。
我之前写过，它被称为只读主分支。
非常简单——禁止任何人将任何内容合并到master，并创建一个任何人都可以调用的脚本。这个脚本将进行合并、测试和提交。脚本不会做任何例外。如果任何分支在单元测试中出现问题，整个分支将被拒绝。
换句话说，在代码进入master之前，提前发出红旗。
这解决了所有问题。
首先，构建始终是干净的。因为除非他的代码保持构建干净，否则没有人能够提交，所以我们根本不会破坏它。
其次，没有破坏任何东西的担忧。因为从技术上讲，你根本无法这样做。你能做的只是从合并脚本得到负面响应。然后你修复错误并告诉脚本再试一次。没有人看到这些尝试，你也不需要道歉。恐惧因素消失了。
顺便说一句，尝试使用rultor.com来在你的项目中实施这种只读主分支的原则。
Translated by ChatGPT gpt-3.5-turbo/42 on 2023-12-16 at 15:43
