注:该文为我对网上发布的DevOps知识库Ledge的一个阅读笔记整理。Ledge(源自 know-ledge,意指承载物)知识平台是基于我们所进行的一系列 DevOps 实践、敏捷实践、精益实践提炼出来的知识体系。
DevOps知识框架概述
对于DevOps研发运维一体化,我在前面也写过了不少文章,包括了基础知识,敏捷研发,持续集成和交付,流水线设计,DevOps和容器云的集成,开源工具集,DevOps能力成熟度模型等方面的内容。
对于DevOps我在前面文章已经强调是企业进行数字化转型,微服务架构转型,云原生解决方案实践的一个关键内容。但是DevOps本身不是简单的类似配置管理,测试,构建,持续集成,发布等开源工具集的集成,更加重要的是整个开发组织敏捷文化的改进。
为何发布了这个框架?
简单来说就是企业数字化转型过程中,究竟对如何实施DevOps,自己应该先做哪些基础技术积累,应该采用哪些开源工具,整个研发管理和开发过程如何改进,实施应该如何分阶段循序渐进等并不清楚。
这就导致很多企业在实施DevOps的时候往往仅仅是个别的开发小组或项目在进行一些敏捷和持续集成的实践,而很难将整个DevOps上升到组织级,形成组织过程资产。
这个知识框架,从发布者的介绍主要包括了如下节点:
今天重点是对当前已经发布的内容做下初步分析和整理。
DevOps流水线定制
不同的企业在实施DevOps的时候可以根据企业实际情况定制不同的流水线。
注意流水线设计最基础的是要实现持续集成和持续部署能力,里面涉及到最基本的内容包括了源代码和配置管理,编译构建,自动化部署。
在整个DevOps最佳实践中实际包括了敏捷研发和过程管理,因此可以看到整个DevOps流水线涉及到了类似Scrum敏捷研发工具之间的集成。而集成的重点主要是组织,团队,产品,项目,项目版本,任务,缺陷。
原来谈的比较多的是CI/CD,即持续集成和持续部署。而在DevOps实施中谈的比较多的是持续集成和持续交付。持续集成过程不包含最终生产环境面向客户的部署和交付过程,而持续交付则单独出来。
持续集成和持续交付的分离,也带来了流水线设计上的区别。简单的流水线你可以从编译构建,一直编排到测试验证到生产环境发布。而在持续集成和持续交付分离后,往往交付流水线需要进行单独设计。
其次,在DevOps和容器云集成的时候,整个自动化部署过程发生了变化,即编译构建完先制作镜像,推送到制品库,然后再从制品库提取镜像+配置信息进行部署。因此在这个阶段还涉及到和容器云的集成,比如常见的实现和Kurbernetes的接口集成等。
在完成了基本的敏捷研发+持续集成+容器云集成这条主线后。还剩余两个重点,其一是测试和质量管理,其二是后续的监控运维。
对于测试和质量管理包括了很多内容,从上面的DevOps元素周期表的橙红色部分也可以看到这块占据了相当大部分内容。如下:
测试本身是一个系统工程,需要覆盖从测试场景分析,测试设计,测试执行,测试评估完整生命周期。中间还需要对测试用例脚本,测试数据等进行管理。
而从DevOps实施角度,更多的是考虑整个测试过程如何自动化,通过将测试过程集成和编排到整个DevOps流水线执行过程中,真正实现研发和QA之间的自动化协同能力。
案例学习
这是一个大的版块,但是实际上这块的内容相对的薄弱,或者说有点乱。虽然整体给出了类似招行,中行,携程,阿里,华为,小米,美团相关的案例,但是整体都很单薄。更多的介绍内容没有,还不如直接看案例介绍里面链接到的具体企业演讲PPT。
上图是大型银行DevOps转型给出的几个阶段,其中给出了三种典型路径如下可以作为参考:
在华为的大规模敏捷开发实践案例里面,给出了大规模敏捷实施DevOps的14条最佳实践也可以作为参考:
企业组织级DevOps和大规模敏捷实施不容易,从scrum敏捷方法论到SAFe大规模敏捷框架,再到DevOps过程实践解决方案,整个敏捷方法论从开发团队到整个企业,整个团队也从几十人扩大到上百人甚至上千人的规模。这个时候需要就是组织架构设计,开发团队的划分,开发团队和整个持续集成过程的协同等。
而一个好的DevOps案例学习和最佳实践至少应该包括如下内容。
DevOps原则和模式
数字化技术(信息技术)的本质目的是创造价值,它的载体是软件,提供价值的是功能特性。越早发布功能特性,便能越快创造价值。采用逐渐增加功能特定的增量式开发方法,能让我们在最短时间内开发出最小可用(MVP)产品。
围绕它周围的优秀技术实践,可以让我们开发出运行良好的软件,并且设计也是好的。这个过程需要自上而下的为之付诸行动。
这块的内容整体给我启发比较大的还是如果构建DevOps文化和学习型组织,里面又涉及到整个知识体系构建,组织和团队人员能力模型和技能评估,架构金字塔等。
架构金字塔,即把软件架构按照不同的粒度进行分组。通过分组的细分,我们能有针对性地对系统架构,进行更好的管理和设计。
一个软件系统是由一系列的应用组成的,而一个应用则由一系列的模块组成,进一步的模块是由代码组成的。举个示例,一个现代的系统是由一系列的后端服务、客户端应用组成的;拆解开一个微服务,则是由一系列的模块组成的。
对于复杂软件系统,需要进行分层和分级,如下:
对于DevOps原则模式这块内容,整体感觉分类还是欠缺,整体还是应该基于组织团队,研发过程,持续集成交付,测试管理等关键过程域给出可行的原则和模式。
对于信通院发布的DevOps能力成熟度模型还是可以作为一个重要的参考标准。该系列标准分为敏捷开发管理、持续交付、技术运营、应用设计、安全风险管理、组织结构及系统和工具等部分,涵盖了软件开发到运维的全生命周期,如下图:
整个评估模型我可以看到融入了多方面的内容,核心是如下三方面
在这三方面以外,我们又看到整个成熟度评估里面很多评估要求的达到本身又希望你采用微服务架构思想,通过容器云来实现持续集成和交付等。这也和我们经常谈到的,微服务和容器云是实践DevOps的另外一个关键要素。
DevOps最佳实践
实际上对于案例学习和最佳实践本身是相互融合的内容,案例很多就是最佳实践。一个DevOps的实施往往涉及到持续集成交付,自动化测试,敏捷研发多个过程域的最佳实践。当然这些最佳实践的侧重点可能不同。
但是所有的最佳实践仍然是围绕DevOps成熟度模型展开。
如果要将最佳实践分离,应该包括:
以上即是最佳实践的一些关键内容点。
DevOps实施手册
知识框架里面将DevOps实施分为如下几个关键步骤:
在前面我就谈到了DevOps实施本身可以分为几个阶段,从最开始的单纯实现持续集成到后续的敏捷研发过程集成,容器云集成,持续交付能力提升等。
当重新思考DevOps的时候,实际上DevOps的实施往往伴随着微服务架构的改造和优化实施,容器云的改造和实施等。即最终实施的是一个完整的云原生技术平台和解决方案,而不是一个简单的DevOps持续集成和交付过程。
从这个意义上讲,DevOps实施实际包括了敏捷研发过程改进,持续集成和持续交付,微服务架构和开发标准规范体系,自动化测试,自动化运维等关键内容。而所有这些内容的实施仍然需要在前期先进行现状分析评估,给出差距分析。然后再结合差距分析情况给出具体的实施演进路线设计。
简单总结
虽然当前DevOps知识平台还不够完善,但是仍然给出了从DevOps基础知识概念,到能力框架,案例和最佳实践,实施路线指引的完整知识架构框架。
个人建议该知识平台还是围绕DevOps能力成熟度模型进一步树立和结构化完善。并对最佳实践里面的一些案例进一步文字化总结和梳理。
ajax 实现三级联动,相当于写了一个小插件,用的时候直接拿过来用就可以了,这里...
Greediness(贪婪型):最大匹配 X、X*、X+、X{n,} 是最大匹配。例如你要用 “....
1 . 目标 演示下图的git reset 各选项的效果。 2. Git Reset操作说明 图中说明:...
Go原生就支持连接数据库,所以在使用 Golang 开发时,当需要数据库交互时,即可...
3月22日消息 外媒 Winfuture 报道,此前微软面向 Insider 预览用户公布了 Window...
2月23日消息 据外媒 Windows Latest 今日报道,借助 Windows 10 Sun Valley 更新...
橡皮擦一个逗趣的互联网高级网虫。 观前提醒本篇文章涉及知识点巨大建议先收藏再...
从另一台机器上复制过来的项目,由于两台机器的库目录不一致,导致了stdio.h等很...
本文实例讲述了正则表达式中的操作符及说明。分享给大家供大家参考,具体如下: ...
这些日子一直在简书上使用markdown写作,已经渐渐的痴迷于这种简洁纯粹的写作方...