DevOps学习笔记--DevOps基本介绍(CI/CD)

1 简介

1.1 DevOps概述

  • 最初是瀑布模型,后来是敏捷开发,现在是DevOps,这是现代开发人员构建出色的产品的技术路线。
    在这里插入图片描述
    在这里插入图片描述
  • DevOps早在 2009 年就已经被提出来了。
  • 单纯从字面上来理解,DevOps 是Dev(开发人员)+Ops(运维人员),虽然名字来源于开发和运维的缩写,但DevOps并不是简单的就是开发加运维。
  • DevOps 所涵盖的角色范围会更广:除了开发、测试、运维还会涉及到项目经理、产品经理,甚至和销售、市场等各个部门,跨职能部门互相合作,完成某一项目或任务。
  • DevOps是通过工具,自动化,来达到这种通过工具链与持续集成、交付、反馈、优化进行端到端整合,完成无缝的跨团队、跨系统协作。即DevOps是一种协作方式

在这里插入图片描述在这里插入图片描述
在这里插入图片描述

1.2 DevOps推崇文化

  • 尊重(Respect)
  • 正视失败(Healthy attitude about failure)
  • 不埋怨(Avoiding Blame)
  • 精益求精
  • 工程质量文化
  • 快速验证文化
  • 客户导向文化

1.3 CI/CD

CI/CD是DevOps最佳实践手段。
CI / CD的采用改变了开发人员和测试人员如何发布软件。
在这里插入图片描述
最初是瀑布模型,后来是敏捷开发,现在是DevOps,这是现代开发人员构建出色的产品的技术路线。随着DevOps的兴起,出现了持续集成(Continuous Integration)、持续交付(Continuous Delivery) 、持续部署(Continuous Deployment) 的新方法。传统的软件开发和交付方法正在迅速变得过时。从历史上看,在敏捷时代,大多数公司会每月,每季度,每两年甚至每年发布部署/发布软件。然而,现在,在DevOps时代,每周,每天,甚至每天多次是常态。当SaaS正在占领世界时,尤其如此,您可以轻松地动态更新应用程序,而无需强迫客户下载新组件。很多时候,他们甚至都不会意识到正在发生变化。开发团队通过软件交付流水线(Pipeline)实现自动化,以缩短交付周期,大多数团队都有自动化流程来检查代码并部署到新环境。

1.3.1 CI(Continuous integration)持续集成

介绍

CI(Continuous integration)即持续集成。在CI环境中,开发人员将会频繁地向主干提交代码。这些新提交的代码在最终合并到主干前,需要经过编译和自动化测试流进行验证。
在这里插入图片描述

要求
  • 团队需要为每个新功能、代码改进、或者问题修复创建自动化测试用例。
  • 你需要一个持续集成服务器,它可以监控代码提交情况,对每个新的提交进行自动化测试。
  • 研发团队需要尽可能快的提交代码,至少每天一次提交。
优点
  • 通过自动化测试可以提早拿到回归测试的结果,避免将一些问题提交到交付生产中。
  • 发布编译将会更加容易,因为合并之初已经将所有问题都规避了。
  • 减少工作问题切换,研发可以很快获得构建失败的消息,在开始下一个任务之前就可以很快解决。
  • 测试成本大幅降低,你的CI服务器可以在几秒钟之内运行上百条测试。
  • 你的QA团队花费在测试上面的时间会大幅缩短,将会更加侧重于质量文化的提升上面。

1.3.2 CD(Continuous Delivery)持续交付

介绍

CD(Continuous Delivery)即持续交付。它可以让软件产品的产出过程在一个短周期内完成,以保证软件可以稳定、持续的保持在随时可以释出的状况。它的目标在于让软件的建置、测试与释出变得更快以及更频繁。这种方式可以减少软件开发的成本与时间,减少风险。
在这里插入图片描述

要求
  • 你需要有强大的持续集成组件和足够多的测试项可以满足你代码的需求。
  • 部署需要自动化。触发是手动的,但是部署一旦开始,就不能人为干预。
  • 你的团队可能需要接受特性开关,没有完成的功能模块不会影响到线上产品。
优点
  • 发布频率更快,因为你不需要停下来等待发布。每一处提交都会自动触发发布流。
  • 在小批量发布的时候,风险降低了,发现问题也可以很轻松的修复。
  • 客户每天都可以看到我们的持续改进和提升,而不是每个月或者每季度,或者每年。

1.3.3 CD(Continuous Deployment)持续部署

介绍

CD(Continuous Deployment)即持续部署。在CD环境中,通过自动化的构建、测试和部署循环来快速交付高质量的产品。某种程度上代表了一个开发团队工程化的程度,任何修改通过了所有已有的工作流就会直接和客户见面,只有当一个修改在工作流中构建失败才能阻止它部署到产品线。
持续部署是一个很优秀的方式,可以加速与客户的反馈循环,但是会给团队带来压力,因为不再有“发布日”了。开发人员可以专注于构建软件,他们看到他们的修改在他们完成工作后几分钟就上线了。

要求
  • 研发团队测试理念比较完善。测试单元的健壮性直接决定你的交付质量。
  • 你的文档和部署频率要保持一致。
  • 特征标志成为发布重大变化过程的固有部分,以确保您可以与其他部门(支持,市场营销,公关…)协调。
优点
  • 发布频率更快,因为你不需要停下来等待发布。每一处提交都会自动触发发布流。
  • 在小批量发布的时候,风险降低了,发现问题也可以很轻松的修复。
  • 客户每天都可以看到我们的持续改进和提升,而不是每个月或者每季度,或者每年。

2 优缺点

2.1 优点

  • 提高发布的频率
  • 更快地将产品新功能推向市场
  • 避免发布的失败率
    在这里插入图片描述

2.2 缺点

3 工具集

3.1 DevOps工具集

  • 编码:代码开发和审阅,版本控制工具、代码合并工具
  • 构建:持续集成工具、构建状态统计工具
  • 测试:通过测试和结果确定绩效的工具
  • 打包:成品仓库、应用程序部署前暂存
  • 发布:变更管理、发布审批、发布自动化
  • 配置:基础架构配置和部署,基础架构即代码工具
  • 监控:应用程序性能监视、最终用户体验

在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述

3.2 CI/CD工具

在这里插入图片描述

4 应用

在这里插入图片描述

参考

1、
2、持续集成cicd和devops
3、DevOps研发模式下CI/CD实践详解指南
4、DevOps、CI/CD
5、DevOps漫谈之一:DevOps、CI、CD都是什么鬼?
6、什么是DevOps?
7、什么是CICD
8、Jenkins与Docker的自动化CI/CD实战
9、Kubernetes中的CI/CD
10、软件开发 CI、CD的简要思维导图,以及常用的软件
11、谁才是世界上最好的 CI/CD 工具
12、DevOps 实践体系和流程总结

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

worthsen

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值