精华内容
下载资源
问答
  • CI/CD
    千次阅读
    2022-03-26 20:19:41

    引入

    这篇文章是自己工作多年对CI/CD的理解,纯属个人见解。

    不想说太多概念性的东西,直接从技术人员实际能接触的过程来展开说说。另外我这篇只是想关注一些通用的流程,细节的不同这里不纠结。比如微服务的CI/CD和单体服务有些不同,如果涉及到容器和k8s,又会有不同的地方。这里都不展开说。

    CI指的是持续集成,CD指的是持续部署。合在一起通常包含这几个过程:

    在这里插入图片描述

    代码阶段

    代码节点也可以叫开发阶段,这个阶段我们一般是本地开发代码,这个阶段首先涉及到一些开发工具比如idea,vscocode等。

    同时,我们需要一个代码托管工具,常用的比如git,当然并不限制一定要用git。

    最后还有一个很重要但是容易被忽略的环节,就是code review(简称cr),cr的重要性无需多说,在国外很多科技公司,cr都是一个强制的流程。国内感觉最近几年对cr也越来越重视了,我之前在的一个公司,代码没有经过cr是不允许发布到测试环境的。

    关于cr阶段使用的工具,不同的公司一般不一样。我见过直接使用idea等开发工具进行cr的,也有用gitlab等托管工具cr的,有些大点的公司有自己开发的cr工具。不过工具不重要,重要的是过程。

    编译阶段

    编译阶段也可以叫构建阶段。首先通常会考虑依赖的问题,比如编译java代码会考虑jdk的版本,pom依赖等这些都是需要解决的。

    其次一个要关注的点就是单元测试,编译阶段一般都会自动运行你在开发阶段编写的单元测试代码(当然前提是你写了,哈哈)。同时单元测试要确保一定的覆盖率,覆盖率很低的单元测试也没啥意义。这样要求我们要一个良好的开发习惯:写单元测试。关于单元测试的种种,不是本文的重点,这里不表。

    编译没问题,并且单元测试没问题,一般就可以构建、打包发布到测试环境了。打包发布常用的工具是jenkins,如果涉及到容器部署,这个阶段通常我们也会打包服务的镜像并且推送的镜像仓库(可以是私有仓库或者公有仓库)。

    测试环境

    我们的服务打包到测试环境之后,一般我们需要在测试环境进行集成测试,所谓的集成测试,就是把流程整合按照接口或者某个特定功能的测试。比如下单的流程,可能涉及很多模块,我们对下单这个流程的测试就属于集成测试。

    生产环境

    生产环境涉及的环节比较多,也是最重要的。毕竟这是最终交付的环节,前面所有的努力都是为这一步做准备。

    当我们发布到生产环境时,通常不会马上进行全量的发布,而是先进行灰度部署。灰度部署是指逐渐将生产环境流量从老版本切换到新版本。通常流量是按比例分配的。例如 90% 的请求流向老版本,10% 的请求流向新版本。然后没有发现问题,就逐步扩大新版本上的流量,减少老版本上的流量。

    这种能最大限度的减少出现故障造成的影响。

    实现灰度发布有很多方案,比如通过前端的cdn技术,后端的方案就更多了,比如基于nginx实现,如果你是基于容器部署,可以通过k8s的ingress实现灰度发布等。

    灰度验证完没有问题,一般就可以进行全网发布了。尽管前面已经做了各种测试了,全量发布后依然不能保证一定不会出问题,因为有些问题可能是流量很大的时候才会暴露。这就要求我们一定要有回滚机制,当线上出问题时能够快速的回滚到上一个版本。

    另外一个关注点就是,服务上线后持续的监控以及出现问题的及时告警机制。这种一般要借助于一些第三方的监控工具,比如Prometheus等。

    更多相关内容
  • 利用jenkins,gitlab,构建自动化的代码发布流水线,并自动部署到k8s集群中。
  • CI/CD 流程以及原理

    千次阅读 2022-03-08 10:32:53
    简介 从CI/CD过程开始,包含所有阶段并负责创建自动化和无缝的软件交付的一系列步骤称为CI/CD管道工作流。使用CI/CD管道,软件发布工件可以从代码提交阶段到测试、构建、部署和生产阶段在管道中移动和前进。这个概念...

    简介

    从CI/CD过程开始,包含所有阶段并负责创建自动化和无缝的软件交付的一系列步骤称为CI/CD管道工作流。使用CI/CD管道,软件发布工件可以从代码提交阶段到测试、构建、部署和生产阶段在管道中移动和前进。这个概念非常强大,因为一旦指定了一个管道,它的一部分或全部就可以实现自动化,从而加快流程并减少错误。换句话说,CI/CD管道使企业更容易一天自动多次交付软件。

    DevOps工程师经常会因为CI/CD中各个阶段的自动化而与CI/CD管道混淆。虽然不同的工具可以使CI/CD中的各个复杂阶段实现自动化,但由于人工干预,CI/CD的整个软件供应链仍然可能被打破。那么,就首先了解CI/CD过程中的各个阶段,以及CI/CD管道为什么对于组织快速、大规模地交付代码至关重要。

    CI/CD阶段:了解人员、过程和技术

    企业应用程序开发团队通常由开发人员、测试人员/QA工程师、运营工程师和SRE(站点可靠性工程师)或IT运营团队组成。他们紧密合作,将高质量的软件交付给客户。CI/CD是两个独立过程的组合:持续集成和持续部署。下面列出了其中的主要步骤。
    在这里插入图片描述

    CI持续集成

    持续集成(CI)是构建软件并完成初始测试的过程。持续部署(CD)是将代码与基础设施结合起来的过程,确保完成所有测试并遵循策略,然后将代码部署到预期的环境中。当然,许多公司都有自己的流程,但主要步骤如下。

    CI:代码提交

    在这里插入图片描述
    人员:开发人员和工程师、数据库管理员(DBA)、基础架构团队

    技术:GitHub、Gitlab、BitBucket

    过程:代码提交阶段也称为版本控制。提交是将开发人员编写的最新更改发送到存储库的操作。开发人员编写的代码的每个版本都被无限期地存储。在与合作者讨论和审查变更之后,开发人员将编写代码,并在软件需求、功能增强、bug修复或变更请求完成后提交。管理编辑和提交变更的存储库被称为源代码管理(SCM工具)。在开发人员提交代码(代码推送请求)后,代码更改被合并到存储在中央存储库(如GitHub)中的基本代码分支中。

    CI:静态代码分析

    人员:开发人员和工程师、数据库管理员(DBA)、基础设施团队、测试人员

    技术:GitHub、Gitlab、BitBucket

    过程:一旦开发人员编写了代码并将其推送到存储库,系统就会自动触发,开始下一个代码分析过程。想象一下这样一个步骤:提交的代码直接进行构建,但在构建或部署过程中失败了。就资源利用率而言,无论是机器还是人力,这都是一个缓慢而昂贵的过程。必须检查代码的静态策略。SAST(Static Application Security Test):SAST是一种白盒测试方法,使用SonarQube、Veracode、Appscan等SAST工具从内部检查代码,以发现软件缺陷、漏洞和弱点(如SQL注入等)。这是一个快速检查过程,检查代码是否有语法错误。虽然此阶段缺少检查运行时错误的功能,但这将在稍后的阶段执行。

    将附加的策略检查放到自动化管道中可以显著减少稍后在该过程中发现的错误数。

    CI:build

    在这里插入图片描述

    CI:测试阶段

    在这里插入图片描述
    人员:测试人员和QA工程师

    技术:Selenium、Appium、 Jmeter、SOAP UI、Tarantula

    过程:发布一个构建过程一系列自动化测试来验证代码的准确性。这一阶段有助于防止错误到达产品。根据构建的大小,此检查可以持续数秒到数小时。对于由多个团队提交和构建代码的大型组织,这些检查将在并行环境中运行,以节省宝贵的时间并尽早将Bug通知给开发人员。

    这些自动化测试是由测试人员(或者称为QA工程师)建立的,他们已经根据用户故事建立了测试用例和场景。他们进行回归分析,压力测试,以检查与预期产出的偏差。测试中涉及的活动有健全性测试、集成测试和压力测试。这是一个非常先进的测试水平。在这里会发现开发代码的开发人员可能不知道的问题。

    集成测试:

    集成测试是使用Cucumber、Selenium等工具来执行的,其中各个应用程序模块作为一个组进行组合和测试,同时评估是否符合指定的功能需求。在集成测试之后,需要有人批准将该组中的更新集移动到下一阶段,这通常是性能测试。这个验证过程可能很麻烦,但它是整个过程的重要组成部分。核查过程中出现了一些新的解决办法。

    负载和压力测试:

    负载平衡和压力测试也使用自动化测试工具(如Selenium、JMeter等)来执行,以检查应用程序在高流量环境下是否稳定和性能良好。此测试通常不会在每个更新上运行,因为完整的压力测试是长期运行的。在发布主要的新功能时,将对多个更新进行分组,并完成完整的性能测试。在单个更新被转移到下一个阶段的情况下,管道可能包括金丝雀测试作为替代方案。

    持续部署:bake和部署

    在这里插入图片描述
    人员:基础设施工程师、现场可靠性工程师(SRE)、运维工程师

    技术:Spinnaker、Argo CD、Tekton CD

    过程:测试阶段完成后,清除了标准的代码就可以部署到服务器中,在那里它们将与主应用程序集成。在部署到生产环境之前,它们将被部署到产品团队内部使用的测试/暂存或beta环境中。在将构建移动到这些环境之前,构建必须经过两个子阶段Bake和Deploy。这两个阶段都是Spinnaker固有的。

    CD:Bake

    Bake是指从源代码中创建一个不可变的映像实例,该实例在生产环境中具有当前配置。这些配置可能是数据库更改和其他基础设施更新之类的内容。Spinnaker可以触发Jenkins来执行这个任务,有些组织更喜欢使用Packer。

    CD:部署

    Spinnaker将自动将烘焙的映像传递到部署阶段。这是将服务器组设置为部署到集群的位置。与上述测试过程类似,在部署阶段执行功能相同的过程。部署首先转移到测试、阶段,最后转移到生产环境,然后进行批准和检查。整个过程由Spinnaker之类的工具处理。

    CD:验证

    这也是团队优化整个CI/CD流程的关键所在。因为现在已经进行了很多测试,所以失败应该很少。但此时的任何故障都需要尽快解决,以便将对最终客户的影响降到最低。团队也应该考虑自动化这部分流程。

    部署到生产环境是使用部署策略(如蓝绿部署、金丝雀分析、滚动更新等)执行的。在部署阶段,将监视正在运行的应用程序,以验证当前部署是否正确或是否需要回滚。

    CD:监控

    人员:SRE,运维团队

    技术:Zabbix、Nagios、Prometheus、Elastic Search、Splunk、Appdynamics、Tivoli

    过程:要使一个软件发行版具有故障安全性和健壮性,在生产环境中跟踪发行版的运行状况是至关重要的。应用程序监控工具将跟踪CPU利用率和发布延迟等性能指标。日志分析器将扫描底层中间件和操作系统产生的日志流,以识别行为并跟踪问题的来源。在生产过程中出现任何问题时,都会通知相关人员,以确保生产环境的安全性和可靠性。此外,监视阶段帮助企业收集有关新软件更改如何为收入做出贡献的信息,并帮助基础架构团队跟踪系统行为趋势和进行容量规划。

    持续部署:反馈和协作工具

    在这里插入图片描述
    人员:SRE、Ops和维护团队

    技术:禅道、ServiceNow、Slack、Email、Hipchat

    DevOps团队的目标是更迅速、持续地发布,然后不断减少错误和性能问题。这是通过slack或电子邮件频繁地向开发人员和项目经理反馈新版本的质量和性能,并在ITSM工具中及时提高票价来实现的。通常,反馈系统是整个软件交付过程的一部分;因此交付过程中的任何更改都会频繁地记录到系统中,以便交付团队可以对其采取行动。

    企业必须评估一个整体的持续交付解决方案,它可以自动化或促进上述阶段的自动化。

    有错误或不足欢迎评论指出!创作不易,转载请注明出处。如有帮助,记得点赞关注哦(⊙o⊙)
    更多内容请关注个人博客:https://blog.csdn.net/qq_43148810

    展开全文
  • (CI/CD)介绍和详细的构建过程

    千次阅读 2022-05-07 19:04:02
    文章目录(CI/CD)介绍及实用说明(CI/CD)介绍CI/CD配置步骤说明前期准备工作配置部署1、关联应用2、关联应用后的显示3、创建部署配置4、创建流水线5、点击实例修改valueDockerfile文件配置说明简单总结 (CI/CD)介绍及...

    (CI/CD)介绍及实用说明

    (CI/CD)介绍

    CI/CD => 工程自动化

    CI 持续集成(Continuous Integration)

    CD 持续部署(Continuous Deployment)

    CI/CD 是一种通过在应用开发阶段引入自动化来频繁向客户交付应用的方法。CI/CD 的核心概念是持续集成、持续交付和持续部署。作为一个面向开发和运营团队的解决方案,CI/CD 主要针对在集成新代码时所引发的问题。具体而言,CI/CD 可让持续自动化和持续监控贯穿于应用的整个生命周期(从集成和测试阶段,到交付和部署)。这些关联的事务通常被统称为“CI/CD 管道”,由开发和运维团队以敏捷方式协同支持。

    Dockerfile简介

    • Dockerfile 一般分为四部分:基础镜像信息、维护者信息、镜像操作指令和容器启动时执行指令,’#’ 为 Dockerfile 中的注释。
    1. 基础镜像信息: FROM 指定基础镜像
    2. 维护者信息: MAINTAINER Jasper Xu sorex@163.com
    3. 镜像操作指令: RUN/ADD/COPY等
    4. 容器启动时执行指令: CMD
    • 针对实际应用中所运用到命令:
    1. COPY: 复制拷贝文件
    2. ADD: 复制新文件、目录或远程文件 URL ,并将它们添加到 中
    3. ENV: 设置环境变量 (eg: ENV = …)
    4. CMD: 运行程序,在 docker run 时运行,但是和 run 命令不同,RUN 是在 docker build 时运行
    • 支持3中种格式:
    1. CMD [“executable”,“param1”,“param2”] 使用 exec 执行;
    2. 推荐方式;CMD command param1 param2 在 /bin/bash 中执行,提供给需要交互的应用;
    3. CMD [“param1”,“param2”] 提供给 ENTRYPOINT 的默认参数
    • 注意:指定启动容器时执行的命令,每个 Dockerfile 只能有一条 CMD 命令。如果指定了多条命令,只有最后一条会被执行

    CI/CD配置步骤说明

    前期准备工作

    1、新建一个分支(develop/test)

    2、将.ci 和.gitlab-ci.yml文件复制到工程的根目录下

    3、将目录.ci/charts/… 下的文件名字改成你的工程名字

    [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-sXZ0L20X-1651921479625)(./img/01.png)]

    • 工程新建完成后push代码到develop ,进行编译和部署,只有第一次通过编译和部署以后才可以配置CI/CD
    • 如果第一次编译不通过的情况,可以根据提示进行代码的修改

    在这里插入图片描述

    配置部署

    1、关联应用

    [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Vx0lfiKj-1651921479627)(./img/03.png)]

    2、关联应用后的显示

    [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Xz67LZMV-1651921479628)(./img/04.png)]

    3、创建部署配置

    [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-QCFvonYJ-1651921479629)(./img/05.png)]

    • 创建部署配置需要注意的地方
      [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-0xft0lwK-1651921479630)(./img/06.png)]

    4、创建流水线

    [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-b1JyDNDM-1651921479631)(./img/07.png)]

    • 注意:
      创建流水线后更新分支代码重新构建,不然看不到实例的运行详情,无法进行后续修改
      [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Kilri0VY-1651921479631)(./img/08.png)]

    5、点击实例修改value

    [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-xsfv3D7e-1651921479632)(./img/09.png)]

    • 修改实例value时要注意的一些地方
    1. 开放devops的网络部署功能
      [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-B54tVMei-1651921479632)(./img/10.png)]
    2. 配置前端的 baseUrl ,静态资源地址等url,需要在dockfile文件中写对应的读取文件
      [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Kqj8JPwF-1651921479633)(./img/11.png)]
    3. 配置对外开发服务的域名,转发打开
      [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-T2ivPx4F-1651921479633)(./img/12.png)]
    4. 配置部署完成重新编译项目,编译成功后访问服务
      [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-NaJ4BEgn-1651921479633)(./img/13.png)]

    Dockerfile文件配置说明

    Dockerfile 一般分为四部分:基础镜像信息、维护者信息、镜像操作指令和容器启动时执行指令,’#’ 为 Dockerfile 中的注释。

    1. 基础镜像信息: FROM 指定基础镜像
    2. 维护者信息: MAINTAINER Jasper Xu sorex@163.com
    3. 镜像操作指令: RUN/ADD/COPY等
    4. 容器启动时执行指令: CMD

    针对实际应用中所运用到命令:

    1. COPY: 复制拷贝文件
    2. ADD: 复制新文件、目录或远程文件 URL ,并将它们添加到 中
    3. ENV: 设置环境变量 (eg: ENV = …)
    4. CMD: 运行程序,在 docker run 时运行,但是和 run 命令不同,RUN 是在 docker build 时运行

    支持3中种格式:

    CMD [“executable”,“param1”,“param2”] 使用 exec 执行;

    推荐方式;CMD command param1 param2 在 /bin/bash 中执行,提供给需要交互的应用;

    CMD [“param1”,“param2”] 提供给 ENTRYPOINT 的默认参数

    注意:指定启动容器时执行的命令,每个 Dockerfile 只能有一条 CMD 命令。如果指定了多条命令,只有最后一条会被执行

    简单总结

    1. 建分支
    2. 复制文件到工程
    3. 修改charts/…为工程名
    4. 关联应用
    5. 创建部署配置
    6. 创建流水线
    • 如有疑问欢迎留言一起讨论,一起学习~
    展开全文
  • 持续集成 (CI) 和持续交付 (CD),也称为 CI/CD,体现了应用程序开发团队用来更频繁、更可靠地交付代码更改的文化、操作原则和一组实践。 CI/CD 是dvoeps团队的最佳实验。这也是敏捷方法的最佳实践。通过自动化集成...

    目录

    CI/CD 定义

    自动化 CI/CD 管道

    持续集成如何提高协作和代码质量

    自动化构建

    持续测试和安全自动化

    持续交付管道中的阶段

    CI/CD 工具和插件

    使用 devops KPI 衡量 CI/CD 成功

    CI/CD 与 Kubernetes 和无服务器架构

    下一代 CI/CD 应用程序

    结论


    CI/CD 是 devops 和敏捷开发的最佳实践。以下是软件开发团队如何通过 CI/CD 管道自动执行持续集成和交付。

    想了解更多相关知识请关注我吧!点击下方蓝色字体领取或者添加V:mashang-zz(备注:999)全套【软件测试/自动化测试】海量资料免费领取

    持续集成 (CI) 和持续交付 (CD),也称为 CI/CD,体现了应用程序开发团队用来更频繁、更可靠地交付代码更改的文化、操作原则和一组实践。

    CI/CD 是dvoeps团队的最佳实验。这也是 敏捷方法的最佳实践。通过自动化集成和交付,CI/CD 让软件开发团队专注于满足业务需求,同时确保代码质量和软件安全。

    CI/CD 定义

    持续集成是一种编码理念和一组实践,它促使开发团队经常实施小的代码更改并将它们签入版本控制存储库。大多数现代应用程序需要使用各种平台和工具开发代码,因此团队需要一致的机制来集成和验证更改。持续集成建立了一种自动化的方式来构建、打包和测试他们的应用程序。拥有一致的集成流程可以鼓励开发人员更频繁地提交代码更改,从而带来更好的协作和代码质量。

    持续交付从持续集成结束的地方开始,并自动将应用程序交付到选定的环境,包括生产、开发和测试环境。持续交付是一种将代码更改推送到这些环境的自动化方式。

    自动化 CI/CD 管道

    有助于存储必须与每次交付一起打包的特定于环境的参数。然后 CI/CD 自动化对需要重新启动的 Web 服务器、数据库和其他服务进行任何必要的服务调用。它还可以在部署后执行其他程序。

    因为目标是交付高质量的代码和应用程​​序,所以 CI/CD 还需要 持续测试。在持续测试中,一组自动回归、性能和其他测试在 CI/CD 管道中执行。

    拥有强大 CI/CD 管道的成熟 devops 团队也可以实现持续部署,其中应用程序更改通过 CI/CD 管道运行,传递的构建直接部署到生产环境。一些实践持续部署的团队选择每天甚至每小时部署到生产环境,尽管持续部署并不是每个业务应用程序的最佳选择。

    实施 CI/CD 管道的组织通常拥有多个 devops 最佳实践,包括微服务开发、无服务器架构、持续测试、基础设施即代码和部署容器。这些实践中的每一个都提高了流程自动化并增加了云计算环境的稳健性。这些实践共同为支持持续部署提供了坚实的基础。

    持续集成如何提高协作和代码质量

    持续集成是一种以流程机制和自动化为后盾的开发理念。在实践持续集成时,开发人员经常将他们的代码提交到版本控制存储库中;大多数团队至少每天都有提交代码的标准。基本原理是,在较小的代码差异上识别缺陷和其他软件质量问题比在长时间开发的较大代码差异上更容易。此外,当开发人员在较短的提交周期上工作时,多个开发人员不太可能编辑相同的代码并在提交时需要合并。

    实施持续集成的团队通常从版本控制配置和实践定义开始。尽管经常检查代码,但敏捷团队会在更短和更长的时间范围内开发功能和修复。实践持续集成的开发团队使用不同的技术来控制哪些功能和代码可以投入生产。

    许多团队使用功能标志,一种在运行时打开或关闭功能和代码的配置机制。仍在开发中的功能在代码中使用功能标志进行包装,与主分支一起部署到生产环境中,并在它们准备好使用之前关闭。在最近的研究中,使用功能标志的 devops 团队的开发频率增加了九倍。CloudBees、Optimizely、 Rollouts和launchDarkly等功能标记工具与 CI/CD 工具集成以支持功能级配置。

    自动化构建

    在自动构建过程中,所有软件、数据库和其他组件都打包在一起。例如,如果您正在开发 Java 应用程序,则持续集成会将所有静态 Web 服务器文件(例如 HTML、CSS 和 JavaScript)与 Java 应用程序和任何数据库脚本一起打包。

    持续集成不仅打包所有软件和数据库组件,而且自动化还将执行单元测试和其他类型的测试。测试向开发人员提供了重要的反馈,即他们的代码更改没有破坏任何东西。

    大多数 CI/CD 工具允许开发人员按需启动构建,由版本控制存储库中的代码提交触发,或者按照定义的时间表。团队需要确定最适合团队规模的构建计划、预期的每日提交数量以及其他应用程序注意事项。最佳实践是确保快速提交和构建;否则,这些过程可能会阻碍团队尝试快速编码和频繁提交。

    持续测试和安全自动化

    自动化测试框架帮助质量保证工程师定义、执行和自动化各种类型的测试,这些测试可以帮助开发团队了解软件构建是通过还是失败。它们包括在每个 sprint 结束时开发的功能测试,并汇总到整个应用程序的回归测试中。回归测试会通知团队代码更改是否使一个或多个跨应用程序功能区域开发的测试失败,其中有测试覆盖。

    最佳实践是允许并要求开发人员在其本地环境中运行全部或部分回归测试。此步骤可确保开发人员仅在代码更改通过回归测试后将代码提交给版本控制。

    然而,回归测试只是开始。Devops 团队还自动化性能、API、浏览器和设备测试。如今,团队还可以在 CI/CD 管道中 嵌入静态代码分析和安全测试、已进行左移测试。敏捷团队还可以使用服务虚拟化测试与第三方 API、SaaS 和其他不受其控制的系统的交互。关键是能够通过命令行、webhook 或 web 服务触发这些测试,并获得成功或失败响应。

    持续测试意味着 CI/CD 管道集成了测试自动化。一些单元和功能测试会在持续集成过程之前或期间标记问题。需要完整交付环境的测试(例如性能和安全测试)通常集成到持续交付中,并在构建交付到其目标环境后完成。

    持续交付管道中的阶段

    持续交付是将应用程序推送到一个或多个交付环境的自动化。开发团队通常有多个环境来暂存应用程序更改以进行测试和审查。devops 工程师使用 CI/CD 工具(例如Jenkins、CircleCI、AWS CodeBuild、Azure DevOps、Atlassian Bamboo、Argo CD、Buddy、Drone 或 Travis CI)来自动执行这些步骤并提供报告。

    例如,Jenkins 用户在描述不同阶段(如构建、测试和部署)的jenkinsfile中定义他们的管道。环境变量、选项、密钥、证书和其他参数在文件中声明,然后分阶段引用。帖子部分处理错误情况和通知。

    典型的持续交付管道具有构建、测试和部署阶段。在不同阶段可以包括以下活动:

    • 从版本控制中提取代码并执行构建。
    • 为自动化安全、质量和合规性检查启用阶段闸门,并在需要时支持批准。
    • 以代码的形式自动执行任何所需的基础设施步骤,以建立或拆除云基础设施。
    • 将代码移动到目标计算环境。
    • 管理环境变量并为目标环境配置它们。
    • 将应用程序组件推送到相应的服务,例如 Web 服务器、API 和数据库服务。
    • 执行重新启动服务或调用新代码推送所需的服务端点所需的任何步骤。
    • 如果测试失败,则执行连续测试和回滚环境。
    • 提供有关交付状态的日志数据和警报。
    • 在完成部署时更新配置管理数据库并向 IT 服务管理工作流发送警报。

    更复杂的持续交付管道可能具有其他步骤,例如同步数据、归档信息资源或修补应用程序和库。

    使用持续部署交付生产的团队可能会使用不同的切换实践来最大限度地减少停机时间并管理部署风险。一种选择是配置金丝雀部署,将流量使用从较旧的软件版本转移到较新的软件版本。 

    CI/CD 工具和插件

    CI/CD 工具通常支持插件市场。例如,  Jenkins列出了1800对个支持与第三方平台集成、用户界面、管理、源代码管理和构建管理的插件。

    一旦开发团队选择了 CI/CD 工具,它必须确保在应用程序外部配置所有环境变量。CI/CD 工具允许开发团队设置这些变量,屏蔽密码和帐户密钥等变量,并在部署时针对目标环境进行配置。

    持续交付工具还提供仪表板和报告功能,当 devops 团队实施可观察的CI/CD 管道时,这些功能会得到增强。如果构建或交付失败,开发人员会收到警报。仪表板和报告功能与版本控制和敏捷工具集成,以帮助开发人员确定哪些代码更改和用户故事构成了构建。

    使用 devops KPI 衡量 CI/CD 成功

    实施 CI/CD 管道的影响可以作为devops关键绩效(KPI) 来衡量。部署频率、变更提前期和事故平均恢复时间 (MTTR) 等指标通常可以通过实施 CI/CD 和持续测试来改进。然而,CI/CD 只是推动这些改进的一个过程,提高部署频率还有其他先决条件

    CI/CD 与 Kubernetes 和无服务器架构

    许多在云环境中运行 CI/CD 管道的团队也使用Docker等容器和kubernetes等编排系统 。容器允许以标准、便携的方式进行包装和运输应用。容器可以轻松扩展或拆除具有可变工作负载的环境。

    有许多方法可以一起使用容器、基础设施即代码 (IaC) 和 CI/CD 管道。免费教程(例如kubernetes与Jenkins或kubernetes与Azure DevOps)可以帮助您探索您的选择。

    另一种选择是使用无服务器架构来部署和扩展您的应用程序。在无服务器环境中,云服务提供商管理基础设施,应用程序根据其配置按需消耗资源。例如,在 AWS 上,无服务器应用程序作为Lambda函数运行,部署可以通过插件 集成到 Jenkins CI/CD 管道中。Azure 无服务器GPS 无服务器计算是类似的服务。

    下一代 CI/CD 应用程序

    您可能想知道 CI/CD 管道开发和管理的一些更高级的领域。以下是一些值得注意的:

    • MLOps是机器学习模型的 IaC 和 CI/CD,支持基础架构、集成和部署到培训和生产环境。
    • 合成数据生成技术使用机器学习来创建测试自动化工程师用来测试 API 和数据科学家用来训练模型的数据集。
    • AIOps,或 IT Ops 中的机器学习和自动化,聚合可观察性数据并将来自多个来源的警报与事件相关联。自动化可以根据需要触发 CI/CD 部署和回滚。
    • 从事微服务工作的团队创建可重用的管道,以支持和扩展Azure和AWS上的开发和审查选项。
      • 工程师在其他领域使用 CI/CD,包括网络配置、嵌入式系统、数据库更改、物联网和AR/VR

    结论

    回顾一下,持续集成打包和测试软件构建并在他们的更改未通过任何单元测试时提醒开发人员。持续交付是向运行时基础架构交付应用程序、服务和其他技术部署并可能执行额外测试的自动化。

    对于经常改进应用程序并需要可靠交付流程的企业来说,开发 CI/CD 管道是一种标准做法。一旦到位,CI/CD 管道让团队更多地关注增强应用程序,而不是关注将其交付到各种环境的细节。

    开始使用CI/CD需要 devops 团队在技术、实践和优先级上进行协作。团队需要就其业务和技术的正确方法达成共识。一旦管道到位,团队应该始终如一地遵循 CI/CD 实践。

    展开全文
  • 前言 ...CI/CD(Continuous Intergration/Continuous Delpoy),持续集成/持续部署,或者持续集成/持续交付(Continuous Delivery),是一种在开发阶段引入自动化来频繁交付应用的方法。从前端的角度
  • CI/CD介绍

    千次阅读 2021-10-19 04:35:46
    CI, CD AND CD CI很容易理解,就是持续集成。但是CD既可以指代码持续交付,也可理解为代码持续部署。CICD之间有很多相似的部分,但是也有很大的区别。 持续集成(CONTINUOUS INTEGRATION) 在持续集成环境...
  • 第一部分:什么是CI/CD 在软件开发中经常会提到持续集成Continuous Integration(CI)和持续交付Continuous Delivery(CD)这几个术语。但它们真正的意思是什么呢? CI/CD 是 DevOps 的基础,CI/CD 侧重于软件...
  • CI/CD的简介以及区别

    万次阅读 多人点赞 2021-06-25 17:38:19
    一、CI/CD的简介 CI/CD是一种通过在应用开发阶段引入自动化来频繁向客户交付应用的方法。 CI/CD的核心概念是持续集成、持续交付和持续部署。 具体来说,CI/CD可让持续自动化和持续监控贯穿于应用的整个生命周期(从...
  • CI/CD的常用工具及原理

    千次阅读 2020-09-10 18:17:34
    CI/CD的常用工具及原理 本篇文章开始,将介绍CI/CD相关工具的搭建过程及CI/CD流水线的实现过程 CI/CD:持续集成/持续发布(continuousintegration/continuous deployment) CI/CD主要运用了jenkins进行对后端的...
  • CI(Continuous Integration):指持续集成,它属于开发人员的自动化流程。CD(Continuous Delivery):指的是持续交付和/或持续部署,这些相关概念有时会交叉使用。持续部署扩展了持续交付,以便软件构建,在通过...
  • Drone CI:搭建自己CI/CD(一)

    千次阅读 2020-05-15 13:47:44
    CI/CD简介 CI全称为Continuous Integration,意为持续集成,是在源代码变更后自动检测、拉取、构建和进行自动化测试的过程,属于开发人员的自动化流程。该解决方案可以解决在一次开发中有太多应用分支,从而导致相互...
  • 作者 | Rahul Jain策划 | 田晓旭近十年来,持续集成(Continuous Integration,CI)和持续交付(Continuous Delivery,CD)领域都取得...
  • 开发人员必知的5个CI/CD工具

    千次阅读 2022-01-24 11:27:50
    一旦你选择了最好的CI/CD工具,你将继续你的DevOps生命周期。如果操作得当,它将能够提高产品质量并鼓励你的团队充满自信地进行发布游戏。 软件工程的最新规范是“以更快的速度同时保证产品质量”。在这种情况下,...
  • GitLab CI/CD 自动化部署全流程

    千次阅读 2022-06-17 00:03:19
    GitLab CI/CD 自动化部署全流程
  • GitLab CI/CD 自动化构建与发布实践

    千次阅读 2021-11-21 22:55:00
    CI/CD 是一种通过在应用开发阶段引入自动化来频繁向客户交付应用的方法。CI/CD 的核心概念是持续集成、持续交付和持续部署。这篇文章中,我将会介绍基于 GitLab CI/CD 的自动化构建与发布实践。如下图所示,整个流程...
  • GitLab CI/CD

    千次阅读 2021-12-01 11:33:40
    GitLab CI/CD 是一个内置在GitLab中的工具,用于通过持续方法进行软件开发: Continuous Integration (CI) 持续集成 Continuous Delivery (CD) 持续交付 Continuous Deployment (CD) 持续部署 持续集成的工作原理是...
  • Jenkins 构建CI/CD(一看就会)

    千次阅读 2021-09-11 14:15:30
    文章目录一、CI / CD1、概念2、CI / CD 方法简介二、jenkins介绍1、Jenkins概述2、Jenkins目标3、Jenkins特性4、产品发布流程三、部署应用Jenkins+Github+Tomcat实战1、准备环境2、访问界面3、安装插件4、邮箱(可选...
  • CI/CD是什么?

    千次阅读 2021-03-04 17:49:04
    CI/CD 是一种通过在应用开发阶段引入自动化来频繁向客户交付应用的方法。CI/CD 的核心概念是持续集成、持续交付和持续部署。作为一个面向开发和运营团队的解决方案,CI/CD 主要针对在集成新代码时所引发的问题。 ...
  • GitLab CI/CD配置使用教程

    千次阅读 2021-04-07 10:10:49
    因为公司需要我们使用GitLab来提交代码,使用GitLab CI/CD 。之前我是没有接触过这个东西的,昨天搞了一天,也是踩了一天的坑,现在记录一下 这个是GitLab CI/CD 的官方文档:...
  • Gitlab CI/CD 简单介绍

    万次阅读 多人点赞 2022-02-10 18:58:28
    基础概念 CICD : DevOps: Job Pipeline
  • 什么是CI/CD流水线?

    千次阅读 2021-06-11 00:01:04
    CI/CD和DevOps领域中,持续交付和持续部署是一个老生常谈的话题。持续集成这个术语最早是在1994年由Grady Booch提出。微服务提出者Martin Flower在2014年...
  • Jenkins与GitLab CI/CD对比介绍

    千次阅读 2020-12-07 10:15:27
    Jenkins与GitLab CI/CD对比介绍1. Jenkins 介绍2. Jenkins 核心特性3. GitLab CI/CD 介绍4. GitLab CI/CD:核心特性5. Jenkins vs GitLab CI/CD 的功能对比6. Jenkins vs GitLab CI/CD 之间的区别7. Jenkins vs ...
  • 如何快速实现一套完整的CI/CD流程

    千次阅读 2022-05-06 15:36:46
    CI/CD实用干货,给你带来一个简单的思路
  • 因为这里主要讲如何配置gitlab-ci/cd,所以jdk及maven安装请自行百度,非常简单,在此略过。(注意:安装完Maven后,要给mvn设置权限,否则会在执行打包时,报“权限不够”问题。使用chmod 777 路径/apache-maven-xx/...
  • 使用Gitlab的CI/CD实现简单的自动发布

    千次阅读 2022-02-07 14:04:45
    但是这样一来问题就是如果要发布文件,必须每次更新完都让服务器管理员去到服务器上执行一下拉取,显然不合理,看到gitlab的ci/cd功能,正好研究下,记录下来。 ci/cd介绍 什么是ci/cd?红帽是这么说的: CI/CD 是...
  • 极狐GitLab CI/CD中的常用预设变量

    千次阅读 2022-02-18 15:02:37
    在GitLab CI/CD中有很多官方预设的变量,这些变量极大地扩展了流水线的功能,比如有一个预设变量为 CI,在GitLab CI/CD的流水线中它的值始终为true,用于表明当前的运行环境是在CI/CD的流水线中,使用它开发者可以将...
  • 持续集成和持续部署CI/CD简介

    千次阅读 2021-03-16 10:45:51
    持续集成(Continuous integration,简称CI)指的是频繁地(一天多次)将代码集成到主干。 持续集成的目的就是让产品可以快速迭代,同时还能保证高质量,它的核心措施是将代码集成到主干之间,必须通过自动化测试,...
  • CI/CD架构简介和配置

    千次阅读 2019-10-15 12:53:31
    CI/CD架构 CI/CD架构简介 CI/CD:持续集成/持续发布 continuous integration/continuous deployment CI/CD主要运用了jenkins进行对后端的开发代码的拉取,经过自动编译,打包,测试后,自动发布到tomcat服务器上...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 602,646
精华内容 241,058
关键字:

CI/CD