定义
DevOps(Development和Operations的组合词)是一种重视“软件开发人员(Dev)”和“IT运维技术人员(Ops)”之间沟通合作的文化、运动或惯例。透过自动化“软件交付”和“架构变更”的流程,来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。
概念提出
单体架构+瀑布模式
瀑布模型是按工作顺序将问题化简,将功能实现和设计分开,便与分工协作,采用结构化的方式分开。
从软件设计、需求分析和定义、软件实现、软件测试、软件运行,到软件维护,规定了他们自上而下、相互衔接的固定顺序,即需求-->设计-->开发-->测试
分布式架构+敏捷开发模式
四个问题
1、多人协同开发问题
敏捷开发的核心理念:既然我们无法充分了解用户的真实需求是怎样的,将一个大的目标不断拆解,把它变成一个个可交付的小目标,然后通过不断迭代,以小步快跑的方式持续开发。
2、多人协同开发问题
为了加快速度增大开发效率,QA工作最好是和开发同步交替进行的,需要将测试环节从后面注入到整个开发环节当中,每次可交付的收拾一个可用的功能集合,对开发交付的内容进行持续验证,这样开发产品的可控性更强。
3、多机器问题
但是这个时候也不是 DEVOPS,而是 DEV+OPS,这时 Ops 的主要职责就是:硬件维护、网络设备维护、DBA 、基础服务维护、数据监控等,运维们擅长写各种部署,监控脚本,减少机械的重复工作,开发模式变成了敏捷开发模式。
4、开发和运维角色的天生对立问题
加入运维,就要协调人员配合,运维的宿命就是维稳,他们是很讨厌变动的;开发的天职确是不断地推代码上线,进行代码变动,更替迭代,这两个工种天生就是对立的。敏捷开发解决了协同开发和多机器部署开发问题,但是没有解决内部人员的矛盾。
微服务架构+DEVOPS
微服务(英语:Microservices)是一种软件架构风格,它是以专注于单一责任与功能的小型功能区块 (Small Building Blocks) 为基础,利用模块化的方式组合出复杂的大型应用程序,各功能区块使用与语言无关 (Language-Independent/Language agnostic)的API集相互通信。
第一,公司发展到BAT这种体量,会招很多人,JAVA,PHP,GO 技术栈都会有,需要协调技术栈;第二,项目到后期往往会变得很大,全部都兑到一个项目里,最直接的后果就是项目变得很大,上线项目启动时间变长,一个BUG可能导致整个业务全线崩溃,最终的后果就是项目变得越来越难以维护,加一个改一个东西几乎搞不动,而且还越来越难重构,牵一发而动全身。
拆分解耦是最终的出路,将项目拆成一个个小的服务单独部署,拆分部署催生出了DEVOPS。
·远程部署一些机器,专门用来管理代码,进行上线工作,由运维事先把上线的规则都给定义好了,开发只要按照他的规则都访问这台服务器进行各自的代码合成和发布,自己上线,能用代码自动完成的事情就绝不要手动解决,这是每个开发人员都在想的东西。运维需要做的事情,慢慢地沉淀到哥哥平台上面,例如监控,有专门的监控组件和可视化,基础服务例如服务器,CDN,负载均衡等基础服务可以外包到云服务厂商,日志也有专门的日志工具,链路追踪也有专门的组件和可视化,还有网关等,渐渐的,只要这些都配置好了,开发也可以做运维的部分工作,毕竟开发才是最了解代码的人,哪里出了问题看看监控日志,可以最快速度定位到问题,于是DEVOPS开发模式诞生了,开发也是运维。
DevOps深度理解
一个软件从零开始到最终交付,大概包括以下几个阶段:产品规划、开发编码、构建、QA测试、发布、部署和维护
DevOps 的三大支柱之中,即人(People)、流程(Process)和平台(Platform)。
DevOps = 人 + 流程 + 平台
人 + 流程 = 文化
流程 + 平台 = 工具
平台 + 人 = 赋能
DevOps实现相关工具
流程前期是产品出原型,UI出设计,然后前后端代码开发,QA测试,最终部署上线。
来源:https://www.zhihu.com/question/58702398