为什么应该使用 CICD 管道

  CICD 被谈论了很多,我想为那些赞成、推荐和使用 CICD 管道的人添加我的声音。我最喜欢构建管道的地方是在它建立后观察一切流动。观看它触发并执行所有那些需要很久才能构建并且需要更长时间才能手动完成的操作,这是一种神奇而有趣的事情。如果您尚未使用 CICD 管道或了解它们,我希望您在此之后希望将它们合并到您的工作流程中。 简而言之,管道只是在每次代码更改时运行的一组脚本。该代码可以是应用程序

  CICD 被谈论了很多,我想为那些赞成、推荐和使用 CICD 管道的人添加我的声音。我最喜欢构建管道的地方是在它建立后观察一切流动。观看它触发并执行所有那些需要很久才能构建并且需要更长时间才能手动完成的操作,这是一种神奇而有趣的事情。如果您尚未使用 CICD 管道或了解它们,我希望您在此之后希望将它们合并到您的工作流程中。

  简而言之,管道只是在每次代码更改时运行的一组脚本。该代码可以是应用程序代码或基础设施即代码。触发管道的最流行方式是通过远程存储库(最大有可能是 GitHub)设置的 webhook。由于提交和推送代码是研发人员工作流程的正常部分,因此这很适合而不会造成麻烦。在触发之后,管道会处理其余的工作,或者至少应该处理。

  CICD 有两个部分:CI 或持续集成和 CD,它可以是持续交付、持续部署或两者兼而有之。持续集成或多或少地检查新代码是不是能够从分支中合并(稍后将详细的介绍分支策略)。通常静态分析、linting 和测试在管道的这一部分运行,但每个团队都有自己的流程或验收标准。对任何分支的更改都有几率发生持续交付,但在长时间运行的分支上最重要(想想main)。在管道的这一部分中,代码被打包到某种可以部署的工件中。对于当今的平台,我敢打赌,持续交付的输出通常是 Docker 映像或 zip 文件。持续部署是工件最终上线的管道部分。应用程序代码已准备好使用,并且基础架构已配置和配置。该工件可以是 Docker 映像、zip 文件、二进制文件或别的类型的可执行文件。

  Jenkins、Spinnaker、CircleCI、Travis、CodePipeline、GitHub Actions 等各种软件都有助于这样的一个过程。除了所有这些名称之外,其背后的想法是让代码以一致、易于重现的方式为部署准备好。然而,它到达那里,任何帮助它的软件最终都无关紧要。目标是一致性、节约时机和部署。很多组织都有关于花哨的管道做古怪和疯狂的事情的文章,但是在构建你的管道时,请记住它背后的目标。成熟的组织在展示其错综复杂的管道之前必须做同样的事情。组织喜欢添加的一些附加功能是警报和反馈、通过环境自动升级、蓝/绿或金丝雀部署、各种级别和样式的测试,等等。所有这些功能都有好处,由工程师和组织来确定最适合他们需求的功能。从基础开始并建立它。

  正如所承诺的,我将先谈谈分支策略。这很重要,因为它会影响研发人员的日常工作流程,以我的经验,最好提前解决这一个问题,并根据分支策略构建管道。在我看来,GitHub Flow最适合今天的 CICD 实践。这个想法是有一个单一的长时间运行的分支(main),作为事实的来源,并且应该始终处于可部署状态。功能分支应该从main分支出来,并在批准后重新合并。如果在任何一个时间里在main中发现错误,每个研发人员都会放弃他们的工作,直到错误得到修复。我曾参与过一些使用这种分支策略的项目,而且似乎效果很好。还有别的策略,因此请探索并找到最适合您和您的团队的策略。

  我想提出的最后一个好处是 CICD 和微服务架构如何齐头并进。围绕微服务的整个想法是保持小而敏捷。取出零件并放入其他零件很容易。迭代也很容易。类似地练习 CICD 功能。将合并保持在main小有助于一次引入更少的错误并使事情进展得更快。拥有更简单的服务也代表着更简单的部署(希望如此),因此也代表着更简单的管道。一切都更容易根据自身的需求创建和销毁,这也使迭代更易和微服务一起构建管道。

  使用 CICD 管道有很多好处,并且软件开发生命周期移动得更快。许多通用和常用的架构和服务都有现成的解决方案,或者团队可以构建自己的管道,因为归根结底它只是一组脚本。最后一个警告是要注意过度设计管道。我已经看到过分的管道和膨胀的过程。我仍然鼓励每个人研究这样的做法,并有可能是在他们的团队中实施。