DevOps基础-5.3-持续交付:持续交付流水线

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/u011541946/article/details/82595865

       在上一篇,我们讨论了持续交付流水线(英文是The continuous delivery pipeline)的第一阶段,即持续集成。在本篇文章中,我们将介绍其余的持续交付流程。在前面文章我把pipeline翻译成了管道,现在这里纠正一下,可能采用流水线翻译更好一些。什么是持续交付流水线呢?请看下面这个图。

        PS:我的实际工作主要的任务就写CI和CD脚本,运行并进行测试。上面这张图,其实很简单,在云平台中,从用户下订单,到利用模板安装虚拟机,然后配置基础环境,然后安装软件服务,然后测试软件无法是否正常启动,然后给用户发邮件,通知他,环境好了可以使用。这是一个典型的环境提供和配置的业务场景,类似的还有软件补丁任务,和升级到新版本和灾难恢复和环境删除操作。这些都可以涉及到很多个Jenkins上的Job,这些Job可能是串联也可能是并联地运行。一个或者多个job其实里面包含了很多业务步骤和配置操作,这些业务步骤和配置操作,我们就需要使用Groovy语言来写pipeline代码,把上下游的任务给串接起来。CD 流水线,你就可以通过用户在云平台,根据自己需求选择下订单,然后云平台通过CD流水线,把环境按照订单要求自动化地交付到用户手中,整个流程就是一个典型地CD流水线。还有建议pipeline还是不要翻译管道或者流水线,感觉就英文pipeline最合适。

        我们将讨论持续交付意味着什么,以及我们认为对于实现这一目标至关重要的五种做法。持续交付的定义是:将每个变更部署到类似生产环境并在此过程中执行自动集成和验收测试的做法。

        关于持续交付的权威性描述是Jez Humble和Dave Farley的一本叫《持续交付》优秀书籍,我强烈推荐它给你们。在关于持续集成上一篇文章,我们讨论了在成功完成每个构建时创建的工件(可以理解为具体某一个模块包,例如zip文件或者jar,war文件等)。不应为测试和生产环境重建这些工件。是的,1.它们应该被构建一次,然后在所有环境中使用。这样,您就知道您的测试步骤是有效的,因为它们都使用相同的工件。

      2.您的工件也不应该被允许改变。它们需要存储并以这样的方式设置权限,使它们不可变。在我在工作中构建的持续交付流水线中,我设置了权限,以便CI系统只能将工件写入工件存储库,而我们调用的部署系统Deployer只能读取工件的读取权限。我们希望工件一次构建并且由于两个原因而不可变。首先,它将在团队之间建立信任。当他们调试问题时,你需要dev和ops以及QA,所有团队都可以确信底层位在不同阶段之间不会发生变化。

        是的,然后快速校验和可以证明你们都在看完全相同的工件版本。是的,第二个原因是可审计性。构建持续交付流水线的一个重要部分是,您可以在源代码管理中跟踪特定代码版本,以成功构建运行系统的工件。沿途重建或更换工件会破坏您的可审计性。在走得更远之前,让我们来谈谈工件如何流经系统。在版本控制系统中检查代码,该提交会触发CI系统中的构建。

       构建完成后,生成的工件将发布到中央存储库。接下来,我们有一个部署工作流程,可以将这些工件3.部署到一个尽可能多的生产副本的实时环境中。您可以将此环境称为CI暂存,测试或预生产。此时,冒烟测试,集成测试和可接受的测试都会执行,并且应尽可能自动化实现。一旦通过所有这些测试,工件就会被发版新版本。

        如果需要,可以将工件部署到生产环境中。最后,您希望拥有一个与生产环境尽可能相同的预生产环境。在云中,这真的很容易。在其他情况下,这可能会更具挑战性。此环境需要包括所有负载平衡器,网络设置,安全控制以及与生产匹配的所有数据。我们将代码移动到此环境的原因之一是进行所有难以在开发人员桌面或构建服务器上完全模拟的验收测试,冒烟测试和集成测试。

        是的,这让您相信您的代码和部署过程都将在生产中发挥作用。这提出了另一个关键点。4.如果在任何时候发生失败,需要停止你们系统的流水线。是的,一个人应该能够使用Andon Cord来锁定CD Pipeline,我们之前已经讨论过了。但更重要的是,CD pipeline不应允许从一个阶段到另一个阶段的进展,而不保证最后一个阶段是否成功运行。PS,只要有一个环境出错,在没有解决问题之前,不可以进入到下一个环节。

        是的,对于我们的CD流水线,我们主要实施了两项检查。首先,如果在部署系统中遇到任何故障,它将锁定并且它将通知所有团队。其次,5.部署的每个阶段都会审核前一阶段,并检查不仅没有发生错误,而且还检查它是否应该处于预期状态。我们在基础架构即代码中提到了这点,重新部署应该使您的系统处于相同的状态。是的,你可以通过使用像Docker retainers这样的可变包装机制或者像Puppet或Chef这样的配置管理工具来实现这一目标。

       但这是信任和信心因素,属于Pipeline地另外一个领域。在构建连续交付管道时,我发现这五种实践非常重要。最后,一旦你计划出你的CD流水线,需要写入代码进行跟踪。

阅读更多

没有更多推荐了,返回首页