持续集成持续部署持续交付_您不进行持续集成！

持续集成持续部署持续交付

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

什么是持续集成&＃xff08;CI&＃xff09;&＃xff1f;

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

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

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

在他们的情况下&＃xff0c;2-3周的冲刺导致以下模式&＃xff1a;

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

对&＃xff1f;

让我们专注于以下分支树&＃xff1a;

管道正在为每个提交运行&＃xff0c;这意味着它们正在将其更改不断集成到代码库中&＃xff0c;对吗&＃xff1f;

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

没有人使用最新版本&＃xff01;

那么……我们如何进行持续集成&＃xff1f;

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

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

但是我们不能跳过代码审查和测试&＃xff01;&＃xff1f;

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

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

为什么&＃xff1f;

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

如果我的拉取请求破坏了代码库怎么办&＃xff1f;

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

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

如果我没有按时完成故事怎么办&＃xff1f;

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

一条规则&＃xff1a;合并之前&＃xff0c;管道必须为绿色&＃xff01;

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

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

听起来很难&＃xff1f; 根据您的需求&＃xff0c;您可以将其简化为简单的if语句&＃xff1a;

您可能想 在Martin Fowler的博客 上内容 。

那现代的测试人员呢

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

监控是新的测试

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

在这里了解 更多 Airbnb如何开发产品的信息 &＃xff1a;

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

如果您的测试人员渴望学习编码&＃xff0c;他们可能会参与编写自动化测试。 怎么做&＃xff1f; 每个拉取请求均由两个人&＃xff08;测试人员和开发人员&＃xff09;开发。 开发人员公开接口&＃xff08;类&＃xff0c;函数&＃xff0c;方法&＃xff09;&＃xff0c;以便测试人员可以开始编写测试。

结果是&＃xff1a;对类固醇编程。

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

摘要

如果您的代码库仅由少量贡献者修改&＃xff0c;则进行持续集成可能不会带来很多好处。 随着团队的成长&＃xff0c;流程开始使您放慢脚步。 您进行的代码审查多于编程&＃xff0c;然后您解决了合并冲突……可爱……运送到生产环境需要很长时间—所有东西都需要一起测试&＃xff0c;而且始终需要快速修复错误……如果此时&＃xff0c;请与您的团队讨论关于过渡。

如果您有任何问题或建议&＃xff0c;请写评论。

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

资料来源&＃xff1a;未来世界

翻译自: https://hackernoon.com/you-dont-do-continuous-integration-vz47534ux

持续集成持续部署持续交付