作者 |Forsyth Alexander

    来源 | outsystems.com

    翻译丨数字兄弟



    在CI/CD和DevOps领域中,持续交付和持续部署是一个老生常谈的话题。CI代表"持续集成"是显而易见的。但是," CD"的解释是模棱两可的,很难区分它代表的是持续交付还是持续部署。此外,得益于Gartner等行业分析机构和CI平台的扩展,持续交付正在产生新的意义。这篇文章解释了它们之间的区别,并探讨了持续交付后续的发展方向。


    什么是持续交付?


    持续交付通常是指在生产中自动准备要发布代码和代码变更。从合并代码变更到交付可用于生产的版本,流程的每个阶段都涉及测试和代码发布的自动化。将代码已上传到源存储库(例如GitHub)或容器存储库(例如Docker)。上传后,运行单元测试、回归测试和性能测试等自动化测试,以保证代码的质量。这一过程结束后,计划执行的内容将自动部署到中间环境,并且可以由运营团队按需实时推送。目标就是将代码准备好部署到生产环境。


    我刚才说的是"部署",那这不就是持续部署吗?其实不是。持续交付的结果是用于部署的就绪的代码,而不是部署本身。简而言之,持续交付可确保交付代码尽可能简单、快速地进行操作,但需要有人批准并推动发布或更新到生产环境。


    什么是持续部署?


    持续部署会自动将经过测试的代码推入生产环境。它基于持续交付的优势,被认为是CI/CD流程的下一阶段。简而言之,没有按需发布产品,这意味着需要人工干预。取而代之的是,代码从集成到发布,然后将测试集成到流程中。


    这种自动化可以为超负荷运营团队减轻负担,并且由于将测试集成到所有流程中,因此更容易发现问题并尽快解决。它还可以确保在验证代码变更和将其投入实际生产之间不会存在任何滞后。需要特别注意的是,由于是自动投入生产环境,因此测试和监控对于持续部署来说更为重要。


    在CI/CD中如何辨别持续交付和持续部署


    在把这两个词摆出来以后,持续交付和持续部署之间的区别就很明显了。持续交付就像让达美乐的送餐人员把比萨饼送到您家门口,在就餐之前您要先检查比萨饼的配料和质量。持续部署就像拥有一条达美乐传送带,定期给您发送一个比萨饼。比萨饼从开始制作的时候就受到监控,以确保它满足您对质量、成分和口味的所有期望和变化。


    但是,当一个平台承诺提供CI/CD而没有详细说明时,您如何辨别它提供的是持续交付还是持续部署?以下是一些区分它们的技巧:


    如果平台描述是将构建"可部署的代码"的过程自动化,那么它提供的是持续交付。例如Spinnaker和AWS CodeBuilder.


    如果平台的描述是在整个CI/CD流程中包括测试和监控,则表示提供的是持续部署。例如Azure DevOps和Red Hat OpenShift.io(Red Hat现在是IBM旗下的公司)。


    如果平台的描述是持续集成,但它还可以实现自动代码准备和自动发布,则很可能会提供持续部署。最著名的例子就是Jenkins,您可以使用它来自动化CI/CD流程中的每个阶段。


    如果没有明显可以提供线索的术语,那这些CI/CD平台很可能会提供持续部署。


    重新定义持续交付


    如果您关注行业分析师和趋势,您会了解到自动化无处不在,DevOps流程也不例外。尽管在受到严格监管的行业中持续部署具有难度,但当前的CI/CD平台更倾向于提供CI/CD(持续部署),而不是CI/CD(持续交付)。例如,当Gartner使用``持续交付''时,他们实际上指的是DevOps流程的自动化,包括部署,而不仅仅停留在交付可部署的代码。


    实际上,自动化的进程随着DevOps而势不可挡,CI/CD可能会变成CI/CD/CO,其中CO指的是持续运营。或者,甚至会出现持续DevOps,它将去除所有字母和斜杠,将整个过程变成一个简单的CD.当然,这是一个有趣的概念。


是白的 我是一个勤奋的爬虫~~
{{uname}}

{{meta.replies}} 条回复
写下第一个评论!

-----------到底了-----------