什么是 CI/CD ?

这篇具有很好参考价值的文章主要介绍了什么是 CI/CD ?。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

cicd,linux,ci,jenkins,git

说在开头
CI、CD 其实是三个概念,包含了一个 CI 和两个 CD,CI全称 Continuous Integration,表示持续集成,CD包含 Continuous Delivery和 Continuous Deployment,分别是持续交付和持续部署。这三个概念之间是有前后依赖关系的。
CI/CD 并不是一个工具,它是一种软件开发实践,核心是通过引入自动化的手段来提高软件交付效率。CI/CD 最终目的:让工程师更快 & 更高质量 & 更简单的交付软件!

持续集成 & 持续交付 & 持续部署
持续集成(Continuous Integration)

什么是持续集成?
定义:持续频繁的(每天多次)将本地代码“集成”到主干分支,并保证主干分支可用

持续集成这个词,起源于极限编程,是当时原始的12种实践之一,持续集成的目的快速反馈问题让产品可以快速迭代,同时还能保持高质量。它的核心措施是,代码集成到主干之前,必须通过编译、代码扫描、安全扫描、自动化测试等。只要编译失败、扫描出高级别问题或测试用例失败,就不能集成。
Martin Fowler 说过,“持续集成并不能消除Bug,而是让它们非常容易发现和改正。”

好处?
(1)通过自动化手段提高集成速度
在传统的研发过程中,一般通过手动方式执行编译、测试、部署,自动化后,可大幅提高集成频次,同时可以减少维护手工脚本带来的低级问题
(2)将问题前置
在每次 commit 时就触发编译、测试,更快的发现问题
(3)防止本地代码大幅偏离主干
如果不是经常集成,主干又在不断更新,会导致以后集成的难度变大,甚至难以集成。
cicd,linux,ci,jenkins,git

触发方式?
自动触发,通过自动化的 CI 服务或工具,自动监听代码库 Git Push & MR 等事件触发

常见的工具如 Jenkins、GitlabCI、CircleCI、GithubActions 等等

蚂蚁支持持续集成平台有:雨燕(前端)、LinkE CI(后端)、伙伴(终端)、ACI(多语言)等

面临的问题 & 阻碍?
理想很丰满,现实很骨感,持续集成理念虽好,但实践过程中却有非常多的问题和阻碍,远没有想象中那么简单!

常见的问题如:
(1)执行环境异构导致结果差异
比如Java测试,用户执行测试一般是本地通过IDEA右击执行测试或 mvn 命令,但是 CI 服务上的环境&机器规格和本地有很多差异,比如 JDK 不一样、Maven 版本不一样、Mac 和 Linux 差异等等会造成很多本地执行可以通过但是 CI 上执行不通过,或者 CI 上执行明显比本地慢的现象。
解决此类问题本质还是减少异构,比如通过容器化方式让执行环境标准化,通过 Maven 缓存提高测试时间等等,同时作为 CI/CD 平台方,也最好将测试、构建的过程透明化(执行机制、清晰的错误码和解决方案),方便在出现问题的时候开发可以很方便的自助排查。

(2)没有严格的测试要求
持续集成的理念是只要有问题一定要及时修复,比如执行测试,必须保证所有case全部通过才能集成到主干,但是在现实中的场景,特别是一些规模大的历史项目,由于历史债等原因,导致测试case无法全部通过或者必须通过重试解决,开发很难有动力去改,导致集成质量低效。
所以,持续集成的前提是,需要有一个心里准备花大精力去治理项目中的一些历史债,尤其是改善历史 case ,补充新 case ,降低 case 噪音,确保每次自动化触发的测试可以准确反馈集成质量!

(3)非常慢的构建 & 测试速度
在 CI 上执行构建或测试的速度非常慢,导致集成效率非常低,这里的慢有两种原因,一种是本身测试&编译就慢,这时需要深入分析,需要结合并行分组、分布式缓存等技术解决。
这里的自动化测试中的集成测试可能会非常慢,所以一般保证在持续集成阶段先让单元测试通过,集成测试放在在持续交付阶段完成。

持续交付(Continuous Delivery)
什么是持续交付?
定义:是持续集成的下一步,持续频繁地将软件的新版本交付到类生产环境(类似于预发),交付给测试、产品验收。
持续交付强调的是“交付”,不管怎么更新,软件是随时随地可以交付的,相比持续集成,持续交付除了交付到类生产环境之外,还会执行一些集成测试、API测试等等,确保交付的产物可以直接交付部署。

触发方式?
手动触发,通过研发平台手动触发(如触发LinkE预发部署流水线),一般交付结果是一个二进制包或者镜像

面临的问题 & 阻碍?
(1)很难保证和线上环境完全一致
由于持续交付的环境很难和线上环境一致,所以可能导致一些问题无法验证,使得交付的产物具备一定风险
探索方案:仿真环境

(2)大量脑壳疼的联调环境问题
经常遇到的场景是虽然本系统开发好了,但是由于各种原因导致上下游系统没有 ready 导致无法持续交付,针对上下游依赖非常多的系统,对联调环境稳定性、效率有非常强的依赖

(3)很难保证严格充分的自动化测试
持续交付最终要做到交付的产物可直接部署线上,那么对代码的质量要求就非常高,需要覆盖全场景充分的测试 case

持续部署(Continuous Deployment)
什么是持续部署?

定义:是持续交付的下一步,“自动”将代码部署到生产环境

持续部署强调的是“部署”,它的目标是,代码在任何时刻都是可部署的,可以进入生产阶段。

持续部署和持续交付触发方式的区别是,持续部署是自动完成的,持续交付是手动完成的

触发方式?
自动触发,通过研发平台配置定时任务,自动获取交付产物进行自动部署。

目前即使在蚂蚁,应该很少有团队和研发平台能够真正做到持续部署,因为持续的部署的条件更加严苛

面临的问题 & 阻碍?
(1)发布条件受限
部分场景上线需要严格的审批的流程 & 频繁的封网
(2)低效手工发布流程
发布过程需要人工一次次确认,灰度和线上发布过程多分组场景下,需要一次次人工确定,不放心自动发布
目前蚂蚁解决方案:无人值守
(3)缺乏线上问题快速准确的反馈机制( 精准 OPS 能力)
没有 OPS 或者 OPS 噪音太大都会导致反馈不及时,这样研发就不敢把部署过程直接交给系统,也是上面发布需要人工确认的根因

目前公司对线上安全要求非常高,持续部署现阶段很难在蚂蚁大规模落地,特别针对类似金融核心这些安全要求非常高的系统,不过其实也未必要“一刀切”,公司还有很多级别不是特别高的应用,可以尝试小范围针对这些应用试点,同时不断持续改进周边 OPS 工具

cicd,linux,ci,jenkins,git

最后
最后,我们来畅想一下,一个优秀的 CI/CD 研发过程应该是什么样子的?
假设开发同学小蚂第一天入职,他打开电脑,通过以下几步完成上线:
第一步:从 AntCode clone 代码到本地,修改了几行代码,本地测试后,通过git commit & push到代码仓库
第二步:push 过程自动触发了 CI 流水线,5 min 后,执行结束,通过钉钉通知告诉小蚂某个测试case失败了
第三步:小蚂本地修改失败 case ,重新 commit & push ,再次触发 CI 流水线,自动执行编译、测试、扫描等,收到钉钉消息,执行通过
第四步:小蚂将功能交给测试&产品验收,发现问题或收到建议,重新到第二步修改代码。
第五步:测试&产品验收没有问题后,手动触发预发部署流水线,并自动生成部署产物交付,后面流程就不用管啦。
第六步:持续部署流水线每几分钟自动检测交付产物包,发现更新后,自动将产物部署到线上。发布成功后,小蚂收到通知小蚂的功能生效啦。

理想状态?
(1)由于发布而导致的加班频次应该大幅减少
(2)开发大部分精力是花在写代码和思考如何写好代码,扫描、部署的事情交由平台自动化完成,并且体验良好,反馈精准。文章来源地址https://www.toymoban.com/news/detail-779628.html

到了这里,关于什么是 CI/CD ?的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • jenkins容器内CI/CD 项目失败问题

    1.1 原因:jenkins容器内: docker.sock 权限 1.2 问题解决方案 文件权限如下: srw-rw---- 1 root 994 0 Jun 30 06:51 docker.sock 进行权限修改 最终权限修改成功为:srw-rw-rw- 1 root root 0 Jun 30 06:51 docker.sock 2.1 问题原因 项目为前端vue,依赖于nodejs 和 npm, 需要为容器安装npm, nodejs 2.2 问题解决方

    2024年02月13日
    浏览(49)
  • 基于 Jenkins 搭建一套 CI/CD 系统

    一、CI/CD环境介绍 本次要实现如下效果,开发人员完成功能开发并提交代码到gitlab仓库,jenkins自动完成拉取代码、编译构建、代码扫描(sonarqube)、打包,再自动化完成部署到Tomcat服务器提供访问。 环境准备三台Centos7.6机器: 服务器 IP地址 配置 包含功能及版本 Gitlab 192.1

    2024年03月13日
    浏览(37)
  • docker部署Jenkins(Jenkins+Gitlab+Maven实现CI/CD)

          GitLab是一个用于仓库管理系统的开源项目,使用Git作为代码管理工具,并在此基础上搭建起来的Web服务,可通过Web界面进行访问公开的或者私人项目。它拥有与Github类似的功能,能够浏览源代码,管理缺陷和注释。       GitLab是由GitLabInc.开发,使用MIT许可证的基于

    2024年02月03日
    浏览(44)
  • gitlab+jenkins+harbor实现CI/CD(2)——初级

    git安装 jenkins主机上安装docker-ce 配置仓库证书 测试 创建项目 创建一个freestyle project 在jenkins主机获取密钥 在gitlab上传公钥 在jenkins上传私钥 输入测试命令后保存 点击立即构建 查看控制台输出 工作路径 构建触发器,定时触发 安装插件 gitlab和 Cloudbee docker 配置gitlab 在网络设

    2024年02月09日
    浏览(50)
  • 什么是 CI/CD ?

    说在开头 CI、CD 其实是三个概念,包含了一个 CI 和两个 CD,CI全称 Continuous Integration,表示持续集成,CD包含 Continuous Delivery和 Continuous Deployment,分别是持续交付和持续部署。这三个概念之间是有前后依赖关系的。 CI/CD 并不是一个工具,它是一种软件开发实践,核心是通过引

    2024年02月03日
    浏览(36)
  • Jenkins CI/CD 持续集成专题三 Jenkins 使用shell脚本打包组件配置流程

    第六步 查看编译状态和产物 到这里,jenkins 配置shell脚本打包组件的完整配置流程就已经完成

    2024年04月29日
    浏览(54)
  • Rancher2.7 + Jenkins CI/CD全流程保姆级最佳实践

    CI方面,官方推荐的视频教程等多是使用极狐Gitlab CI,但社区版极狐每月仅400分钟构造时间,额外购买价格为1000分钟/68元,而私有化部署极狐Gitlab对比部署使用Jenkins,具有更高的成本、更狭窄的适用面,且如果个人使用其代码仓库功能,并不比Gitee可靠。 Gitee 同样提供CI服务

    2024年02月05日
    浏览(76)
  • [Docker实现测试部署CI/CD----Jenkins集成相关服务器(3)]

             SonarScanner 是一种代码扫描工具,专门用来扫描和分析项目代码质量。扫描和分析完 成之后,会将结果写入到 SonarQube 服务器的数据库中,并在 SonarQube 平台显示这些数 据。         在 SonarQube 官网的帮助文档中可以下载 SonarScanner。这里下载一个 Linux 系统下使

    2024年02月14日
    浏览(39)
  • nodejs前端项目的CI/CD实现(二)jenkins的容器化部署

    docker安装jenkins,可能你会反问,这太简单了,有什么好讲的。 我最近就接手了一个打包项目,它是一个nodejs的前端项目,jenkins已在容器里部署且运行OK。 但是,前端组很追求新技术,不断地升级Nodejs的版本,之前是14,现在需要升级到16。 也就是说,原本运行顺畅的打包不

    2024年01月20日
    浏览(53)
  • Jenkins分布式实现: 构建弹性和可扩展的CI/CD环境!

    Jenkins是一个流行的开源持续集成(Continuous Integration,CI)和持续交付(Continuous Delivery,CD)工具,它通过自动化构建、测试和部署过程,帮助开发团队更高效地交付软件。Jenkins的分布式实现允许将任务分散到多个计算机上执行,从而提高系统的弹性和可扩展性。本文将深入

    2024年02月01日
    浏览(60)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包