DevOps概念介绍
1 DevOps起源
随着互联网给人们的生活带来的极大的便利,提升了生产力,提供了众多娱乐的项目,改善了人们的生活,目前计算机软件变成了非常赚钱的产品之一。
一款产品从零开始到最终交付大概包括如下几个阶段:规划、编码、构建、测试、发布、部署、维护。
最初,程序比较简单,工作量不大,程序员一个人可以完成所有阶段的工作,但是随着软件产业的日益壮大,软件的功能也在不断的增加,随之而来的就是复杂度不断的攀升,导致一个程序员无法在有效的时间完成所有的工作,随后开始精细化分工。
精细化分工后一款产品从零开始到最终交付由不同的团队分工完整:开发工程师、测试工程师、运维工程师
分工之后,开发人员完成编码工作之后,将代码交给QA(质量保障)团队进行测试,然后将最终的发布版交给运维团队去部署到生产环境对用户提供服务,既开发、测试、部署。
但是早期的软件交付被人们称为瀑布模型。瀑布模型就是等一个阶段所有工作完成之后,才能进入下一个阶段。
这种模型适合条件比较理想化(用户需求非常明确、开发时间非常充足)的项目,大家按部就班的执行自己本质工作即可,但是随着用户的需求不断增加,软件市场的竞争变得越加的激烈,根本无法实现理想化的交付,在这个情况下,大家发现,笨重迟缓的瀑布式开发已经不合时宜,于是软件开发团队引入了一个新的概念,那就是大名鼎鼎的——敏捷开发。
敏捷开发在2000年左右被人们所关注,是一种能应对快速变化的市场需求而诞生的思想。就是把大项目变成小项目,把大时间点变成小时间点。
敏捷开发可以大幅的提高开发团队的工作效率,让版本更新的速度变得更块,更快的发现问题,产品更快的交付到用户手中,团队也可以快速得到用户的反馈,从而进行快速的响应。
2 CI/CD概念
在敏捷开发下,更新迭代速度预发加速增长,平常我们在公司难免会遇见一周两次的服务升级,或是更新等工作;但是手工对服务器应用的升级已经不够满足公司快速迭代部署、回滚、开发代码发布维护与问题发现;这时就需要开发人员使用代码持续集成和持续交付的工具,从而产生了 CI/CD 的概念。
持续集成CI
持续集成(Continuous Integration,简称CI)指的是频繁地(一天多次)将代码集成到主干。 持续集成的目的就是让产品可以快速迭代,同时还能保证高质量,它的核心措施是将代码集成到主干之前,必须通过自动化测试,只要有一个测试用例失败,就不能集成。
通过持续集成,团队可以实现敏捷开发(速度快,效率高),简而言之,敏捷开发很大一部分要归功于持续集成。
持续部署CD
持续部署则是在持续交付的基础上,把部署到生产环境的过程自动化。
虽然敏捷开发大幅提升了软件开发的效率和版本更新的速度。但是它的效果仅限于开发环节。研发人员发现运维那边成为了瓶颈。开发频繁的更新导致运维工作变得不稳定。
运维工程师与开发工程师有着完全不同的思维逻辑,运维在团队的理念就是”稳定“不出问题。
什么情况下最容易出问题?发生改变的时候最容易出问题,所以运维排斥”改变“。
于是开发与运维两者之间的矛盾就爆发了,这个时候,大名鼎鼎的DevOps登场了。
3 DevOps
DevOps近年来作为一个热门的概念,频频出现在各大技术社区以及大牛的文章中,备受行业大咖的追捧。有人说它是一种工具,还有人说他是一种思想,更有甚者说他是一种哲学。
DevOps是Development Operations两个组合词的缩写,Dev(开发)和Ops(运维)。
DevOps的维基百科定义是这样的:
DevOps是一组过程、方法与系统的统称,用于促进开发、技术运营和质量保障(QA)部门之间的沟通、协作与整合。
这个定位稍微有些抽象,反正它不是一个特定的软件、工具、或平台。我们可以把它理解成一种思想,或者是一个目标,这个目标最终就是让开发和运维部门之间更好的沟通合作,通过自动化的流程使得软件整体过程更加的敏捷和可靠。
第一步:技术的变革肯定是思想先行!改变传统运维的观念(洗脑),如果观念不能改变,思想最终无法落地。
第二步:梳理DevOps自动化流程的规范和标准。
第三步:在DevOps的流程下,运维人员会在项目开发期间介入到开发过程中,了解开发人员使用的系统架构和技术路线,从而定制合适的运维方案。
第四步:开发人员在运维环境部署的初级参与到系统部署中,提供系统部署的优化建议。(如果第一步失败,即使将员工放在一起,也不会产生火花)。
在思维和流程改变的同时,想要充分的落地DevOps目标,当然离不开软件和平台的支持。
下边这张图就是在DevOps生态圈中令人眼花缭乱的工具/平台/软件。
从上边这张图可以明显看出一个软件从无到有的整个阶段会用到的软件/平台/工具,DevOps生态圈几乎已经全部贯穿了,而不仅限于开发阶段。
在DevOps流程下可以满足现在软件市场不断快速更新/迭代的需求。
评论区