当构建几乎总是被破坏时如何保持效率

我在一个中型团队中工作，该团队共享相同的源代码，并且有持续的集成，但是由于我们所有人都必须在同一个分支中工作，因此构建几乎总是被破坏。

我们还有一条规则，该规则最近被引入以减轻损坏的构建，该规则指出在构建为红色时不允许任何人签入。

话虽这么说，一天中每个人都只有几个10-15分钟的窗口，我们可以在那里办理登机手续。

并且随着团队的成长，签到机会的窗口会进一步缩小。这迫使开发人员在本地积累他们的更改，从而导致更大的更改集，这甚至更加难以确保更改不会破坏任何内容。您可以看到恶性循环。

您能推荐什么使我在这样的环境中保持有效的工作。另外，请记住，我是开发人员，而不是经理，并且不能改变流程或其他人的行为。

首先，此注释：

...拥有分支意味着额外的复杂性，因此额外的工作...

是完全错误的。我经常听到不习惯分支的人听到的消息，但这仍然是错误的。

如果您有许多开发人员在本地累积更改，则他们的本地更改构成了主存储库的实际分支。

当他们最终推动时，这实际上是合并。

您的分支和合并是隐式的事实并不会消除您所担心的额外复杂性，而只是将其隐藏。事实是，明确此流程可能会帮助您（多个=整个团队）学会管理它。

现在，你说

红色建造时，不允许任何人签入

但是在这种情况下，构建将永远无法修复，因此不可能十分准确。

通常，如果在本地进行构建是合理的（即，构建不是太大或太慢），则开发人员应在继续进行之前进行此操作。

我认为情况并非如此，因为那样一来他们就不会推送损坏的版本，但是如果您能阐明这一点，那就太好了。

总的来说

当构建几乎总是被破坏时如何保持效率

是：停止破坏构建。

开发人员...在本地积累他们的更改...您可以看到恶性循环。

确实是恶毒的。在本地累积更改是一个大的红旗，表示在开发过程中某些东西严重腐烂。它完全破坏了拥有版本控制系统的整个目的。

只要您不想改变流程或其他人的行为，最自然的解决方案是建立自己的分支机构，并使用它“累积”您的更改（当您获得团队合作时进一步与团队分支集成）机会）。

实际上，如果有更多像您这样的人，您甚至可以协作并建立共享的开发分支，以自由地交换您的更新，而不会受到不称职的管理思想的干扰。分支允许采用多种不同的方式来简化团队合作。

• ^{旁注，经理每次执行或说出一些迫使您避免提交的事情，将代码保留在本地，将其词翻译成粗体和简单的“我无能”。}

请记住，我是开发人员，而不是经理，并且不能过多地更改流程或其他人的行为...

为了精确起见，您实际上可以做到，这些都是影响力和沟通技巧，实际上并不需要掌握改变事物喜好的能力（如果需要，可以在网络上搜索“管理” '对更多详细信息感兴趣）。

但是，这相当麻烦且费力，而且我可以完全理解一个人是否只愿意继续专注于编码，而很少参与政治活动，因此，即使您不愿意（即使理论上也可以），这也是可以理解的。:)

我对您无法改变环境的想法很敏感，但是我认为这种情况对您作为程序员的专业性构成了严重挑战。

如果外科医生用干净的手术刀存放脏手术刀，会发生什么情况？如果水管工不测试他安装的管道会怎样？如果小提琴家总是跟管弦乐队不合时宜怎么办？

为什么程序员应该免于团队合作和礼貌？作为该团队的成员，您应对结果承担责任。忽视团队是不负责任的，因为它破坏了自己的努力。

我很好奇“没有人在建房时可以办理登机手续的规则是红色的”规则从何而来？如果那可以使每个人都集中精力修复构建，这是一个好规则。我会尝试以身作则，并在损坏时帮助修复。面对现实吧，您无论如何都无法完成任何其他工作。如果这让您感到烦恼，那么我建议您为这些担忧表达意见。积极尝试改善状况的人的声音比在角落里抱怨的人具有更大的影响力。

我认为，只要您认为自己只是“开发人员”，就无法更改将要遭受此问题困扰的事情。

您需要做的是，每次有人破坏构建时，您都需要还原存储库中的所有提交，然后告诉那个人他破坏了构建并且需要停止。您还需要向经理解释这种情况，并告诉他您的团队的生产力正因为这个问题而受到影响。

您需要尽一切可能更好地更改流程，而不是请求许可，然后说对不起。

我认为您和您的团队处于需要更改流程并且无法有效使用该破损模型的情况。我还认为，认识到该问题后，您有责任对此做一些事情。如果没有人可以对这个问题做任何事情，那么您就是必须这样做的人！

我可以与您的困境相关，我最近的工作项目也遇到了类似的情况。我们最终实现了一种“热土豆”系统，在该系统中，最近破坏了构建的开发人员不得不保姆/保姆/监视它，直到修复 并通过我们的所有验证测试为止。

这是成功的，因为构建和验证测试通常要花费大约4个小时，因此中断构建意味着您在进行实际工作时会浪费半天的时间。不用说，这导致开发人员在将分支合并到主干之前可以更有效地使用分支。对于大多数开发人员而言，以前的想法是“如果我的代码被破坏，我将让CI构建系统通知我”。

只需对CI系统进行简单更改即可：破坏构建的任何更改都会自动回滚。更好的是，让CI存储库成为暂存区域，其中只有当构建为绿色时，更改才会被推送到权威存储库。Gerrit之类​​的工具可以在这里提供帮助。

另外两件事可以在这里有所帮助：

• 您的团队可以在本地测试CI构建吗？如果您检查自己没有破坏构建，或者至少不要以通用的方式破坏构建，而不必提交并触发管理和团队关系。
• 有多种方法可以定义残破的版本，具体取决于您如何配置CI。这包括定义坏的-在繁重的开发中，我们不会将失败的测试视为失败，而是要努力实现的另一个目标。

但是您应该真正查看分支机构。