在我们的上一篇文章中，我们讨论了三种不同程度的连续交付软件。我们讨论了持续集成，持续交付和持续部署。你希望将这些视为彼此之间的构建块。它们中的每一个都依赖于正确实施和采用的前一步骤（持续集成->持续部署->持续交付）。为了开始这个视频，让我们回到Jez和Dave的指导，让我们的软件始终保持工作。在本文，我们将介绍六种我们认为对于实现持续集成（Continuous Integration ，CI）至关重要的实践。
在持续集成构建系统中，在每次提交时，都有一个自动触发的构建，它自动拉代码，进行构建，运行所有单元测试，和其他代码验证步骤，并在最后打包工件（artifact）以及构建状态和生成一个日志。如果测试失败，则整个团队的构建都会中断。要修复构建，需要新更改运行完全相同的过程。持续集成为任何代码缺陷生成快速反馈循环，促进自动化测试的编写，并减少返工。在进行持续集成时，我认为有六种做法很重要。
让我们来看看他们。第一种做法，所有构建都应该通过咖啡测试。构建应该花费比获得一杯咖啡所花费的时间更少的时间。现在，我不是在谈论这些时代潮人们的冷饮，而且我不是咖啡师，所以出于实际目的，让我们称之为五分钟。构建时间越长，人们自然会等待更多的更改，这会增加您的工作进度。第二中做法，小量修改提交。寻求每次提交提交最少量的代码。团队中的每个人都可以轻松地进行小改动。
它还可以更容易地隔离故障。哦，是的，失败。第三做法，不要让构建破坏。当您使构建中断时，您将阻止交付。我经常建议团队聚在一起，签订协议，你想推迟会议或停止所有其他工作，直到修改版本为止。现在，这纯粹是一个文化问题，以及如何处理破碎的构建，为您的其他交付文化奠定基调。好吧，谈到文化，这将引导我们进入第四个做法。
您希望使用基于主干的开发流程。现在，我知道这对某些人来说实际上是一个热门话题，但无论如何我都会去那里。人们在开发，分支和基于主干时使用两种主要做法。基于主干的意味着没有长时间运行的分支，并且主干（也称为主分支）始终集成在所有开发人员的本质上。现在，所有开发人员都在使用trunk进行工作，并且每天多次提交回trunk。现在，开发人员不是保持单独的代码分支，而是分支代码并使用功能标志。
我曾在基于分支和基于主干的样式中工作过，我强烈建议使用这种基于主干的方法。它有助于将工作保持在正在进行的有限工作中，确保经常检查和检查代码，并减少浪费和容易出错的返工，尤其是在您尝试合并分支时。 DevOps报告状态明确指出这种做法是高绩效团队的标志。好吧，让我们继续介绍第五种做法，不要让有问题的测试通过，而是修复它们。你有没有曾经在某些地方工作，有时候测试有时会失败，有时会因为没有明显的原因而通过？我有，而且不是很有趣。
你无法知道你是否真的可以信任这个版本。说到信任，这将带我们介绍第六种做法，构建应返回状态，日志和工件。状态应该是简单的通过/失败或红色/绿色。构建日志是运行的所有测试和运行的所有结果的记录。应该上传工件并使用内部版本号标记。这增加了信任，确保了可听性以及工件的不变性。好的，这就是六种做法。希望这些可以帮助您开始持续的集成工作。
