您不进行持续集成！

今天，我将谈论开发人员的一个误解：持续集成是关于运行自动化集成管道的…

什么是持续集成（CI）？

持续集成是一种以连续方式集成更改的过程。 这是什么意思？

想象一个团队，有6个人-3个开发人员和3个测试人员。 他们在每个季度发布的项目上工作。 他们使用2-3周冲刺的“准” scrum。 产品负责人将故事拆分成一个单一的冲刺。 该团队遵循Github分支架构：

• 开发分支-所有故事完成后将合并，并为故事（拉请求）提供单独的分支。
• 每个开发人员都有自己的故事。 在将拉取请求合并到开发分支之前，他们要求其他开发人员进行代码审查，并要求测试人员进行测试。 它们具有在每次提交时运行的自动集成管道。 管道包括短绒棉布，测试和捆绑（创建可运输的包装）。

在他们的情况下，2-3周的冲刺导致以下模式：

• 开发人员“ A”有6-7天的实施时间，
• 开发人员“ B”有一天的代码审核时间，
• 开发人员“ A”有一天可以在代码检查后应用更改，
• 测试人员大约需要3-7天的测试时间。

对？

让我们专注于以下分支树：

流水线正在为每个提交运行，这意味着它们会将其更改不断地集成到代码库中，对吗？

没有！ 开发分支的最新状态分布在3个不同的分支（拉请求）中。 这意味着管道分别确认了每个拉取请求的集成，并且开发分支有点“陈旧”……

没有人使用最新版本！

那么……我们如何进行持续集成？

让我们假设这个团队了解他们做错了什么。 他们希望以持续集成的方式开发软件。 开发过程必须如何改变？

每个开发人员每天至少需要合并一次更改。 当他们经常合并内容时，他们会使用最新的代码库。

但是我们不能跳过代码审查和测试！？

是的，您不能，也不应。 每个请求请求都应由其他开发人员进行审查。 如果所有反馈都已解决，则功能完备性检查已经完成，并且集成管道为绿色，您可以继续进行...

...是的，在将故事移交给测试之前，您应该合并提取请求。

为什么？

1. 通过了Linters，通过了测试，并且已经构建了软件包。 自动化集成管道的重点在于以自动化方式运行测试。 如果您仍然需要测试人员，那么自动化是毫无意义的……
2. 手动测试会使分支陈旧！ 开发分支不包含您的拉取请求中的更改，因此该分支是陈旧的。 您的拉取请求没有在一天之内合并下来，因此拉取请求已过时。

如果我的拉取请求破坏了代码库怎么办？

好吧……您的更改阻止了其他人的合并，您必须尽快修复它。 但是不用担心...。 您的好友可能会帮助您找到问题并解决。

但这带来了很大的压力！ 最后，事实并非如此。 每次事件都会使您成为一名更好的程序员，并给其他团队成员带来情感上的约束。 您将在代码审查期间学习更多的注意，在实际合并之前先进行尝试。 这些情况会教您关心他人，并表明您可以信任自己的团队。

如果我没有按时完成故事怎么办？

别担心。 在一天之内完成所有工作非常困难。 如果该软件尚未交付生产，并且您的故事还没有100％完成。 没事。 要求审查。

一条规则：合并之前，管道必须为绿色！

理想情况下，永远不要合并未经测试的代码，因为以后很难更改它。 我鼓励您在进行持续集成时进行测试驱动开发（TDD）。

如果您的公司将软件交付生产，则可能需要功能切换。 功能切换开关是允许在生产环境中禁用功能的开关。

听起来很难？ 根据您的需求，可以将其简化为简单的if语句：

if (process.env.NODE_ENV !== 'production' ) {
  // your unfinished code.
}

您可能想 在Martin Fowler的博客 上阅读更多内容 。

那现代的测试人员呢

Airbnb和Netflix不雇用他们。 他们的开发人员编写所有自动化测试。 如果某些东西太昂贵而无法自动化，他们会跳过它。 他们如何确认某些东西坏了？ 他们有负责站点监视的站点可靠性工程师（SRE）。 当SRE识别出系统中的异常时，他们正在调查引入了哪些更改。 之后，他们决定如何处理它-恢复或修复它。

监控是新的测试

请记住：Airbnb运行着世界上最好的软件公司之一。 实施他们的流程将很昂贵，并且很难反映到您所在的公司。

在这里了解 更多 Airbnb如何开发产品的信息 ：

我想，您的公司已经雇用了测试人员，并且不想摆脱他们。 在这种情况下，测试人员可以专注于难以自动化的事情-执行手动探索性测试，并验证视觉元素。

如果您的测试人员渴望学习编码，那么他们可以参与编写自动化测试。 怎么做？ 每个拉取请求均由两个人（测试人员和开发人员）开发。 开发人员公开接口（类，函数，方法），以便测试人员可以开始编写测试。

结果是：对类固醇编程。

免责声明 ：最后一段是经验性的。 在为我的一位前雇主工作时。 两位，我和我的同事正在编写自动化测试套件。 我们正在提供标记为已跳过的测试用例，而开发人员正在其拉取请求中对其进行修复。 结果，我们提供了更好的质量，没有错误，并且我们改善了团队内部的沟通。 每个人都了解此功能的含义以及代码的工作方式。

摘要

如果您的代码库仅由少量贡献者修改，则可能看不到进行持续集成的许多好处。 当您的团队成长时，流程开始使您放慢脚步。 您进行的代码审查多于编程人员，然后解决合并冲突……非常可爱……交付生产需要花费很多时间-所有东西都需要一起测试，并且始终需要快速修复错误……如果此时，请与您的团队讨论关于过渡。

如果您有任何问题或建议，请写评论。

您可以在Medium和Twitter上与我联系或关注我。

资料来源：未来世界

From: https://hackernoon.com/you-dont-do-continuous-integration-vz47534ux