在我之前的工作中，有一位主管下达了一项"100个成功的主干构建"的命令，并得到了副总裁的批准水平。在乍一看，这似乎是一项"伟大"的任务。在这之前，构建经常被破坏，而且常常是连续几周。然而，由于我是负责实现这一目标的人之一，我在好的。飞行前似乎很有帮助，听起来是个很棒的主意。这个概念是给开发人员一种测试构建（和测试）的方法在签入代码之前，在生产环境中，done-显然-确保签入后代码可以工作，因为-您已经测试过它。对吗？事实上，这并不奏效好吧。那个我们遇到的最大障碍是多个开发人员对同一代码进行更改。以这个场景为例示例：显影剂A更改代码并在飞行前运行。飞行前成功，一切顺利，代码已签入。开发人员A继续写代码.开发者B对一些相同的文件进行更改，运行preflight，但失败了！哦，云服务器哪家好，不！开发人员B不签入代码，并致力于实现修复。开发者A完成一组新的更改并在飞行前运行，而开发人员B仍在修复他/她的代码中的问题。开发者A的飞行前通过，一切正常好吧。开发者B最终修复了他/她的代码并成功地运行了preflight。然而，当开发人员B试图签入代码时，他注意到了冲突，物联网工程是什么，因为开发人员A已经更改了相同的代码。开发人员B现在必须解决这些冲突。如果开发人员B比他聪明，他正确地修复了它们，代码没有中断，但是开发人员B是否也运行开发人员A运行的相同测试，以确保他没有破坏开发人员A的更改？我意识到无论飞行前有没有，上述情况都会发生。然而，根据我的经验，在使用飞行前发生这种情况的频率要高得多。原因是飞行前要多加10分钟或更长的时间来签入，而开发人员B经常会覆盖开发人员A的更改，以响应经理询问为什么签入更改需要这么长时间。后来，在发布测试期间，开发人员A无法理解为什么他确信在运行干净的飞行前检查后签入的更改会消失在thin中空气。给予在这种情况下，我设计了一个更好的方法：与其担心损坏的构建，不如关注构建中断后的快速（如果可能的话，自动）恢复。要说服管理层相信这一点需要做一些工作。但结果是更快更清洁的开发，而不是担心"永远不会破坏"一个构建。在乌托邦的场景中，构建永远不会崩溃，但实际上它们总是会崩溃。我通过确定构建失败的原因，并采取适当的方法确保不再发生破坏，或者如果发生破坏，我们可以恢复很快。关于飞行前，它们在这些ituations:共享代码库，但每个开发人员只在一个平台上开发。在具有基本测试的所有平台上运行飞行前测试，以确保您的代码在所有平台。敏感具有大量依赖项和构建的代码区域通常会因更改此代码而中断。在更改了代码的这些区域后运行一个飞行前程序，并可能尝试重新设计代码，使其不那么敏感，不会像往常一样中断。在下面的代码中，预飞没有那么有用场景：针对每个登记入住（我知道有些人会不同意，说这应该是理想的，但是我发现它减慢了开发速度，德国云服务器，实际上导致的错误比解决它们的错误还要多）。如果你有一个代码库，它的构建只需要几分钟（或几秒钟），那么肯定会在飞行前运行。但是，我很少看到这样的构建快。快真正敏捷的最重要的方法是在修复损坏的构建时保持敏捷。从损坏的生成中恢复应该在几分钟内完成，而不是数小时。公司应该减少对确保"没有损坏的生成"的关注，而应该更多地关注从损坏的生成中自动恢复。一个设计良好的CI系统应该能够检测出损坏的构建并自动采取所需的操作来修复它们，例如，回滚破坏了生成的更改，确定生成是否已损坏到基础结构（磁盘空间已满、服务器超时、内存错误等），并尽可能自动地解决这些更改。当然，它还应该通知所有需要的各方，构建已损坏，以便可以修复它离开。进来事实上，这在很大程度上是一个文化问题，因为我们习惯于认为"红色是不好的，所以我们必须没有红色"，武汉大数据，而实际上应该是"红色如果长时间保持红色就不好"。当管理层开始制定指示时对于"不破坏构建"来说，这会导致人们要么停止进行更改，智能家居物联网，要么为了"不破坏构建"而以一种不那么敏捷的方式进行开发。在许多方面，对破坏构建的恐惧通常会阻碍创造力。