DevOps 入门介绍


DevOps 从何而来

DevOps 的“祖师爷”是比利时一名独立 IT 咨询师 Patrick Debois。2007 年,他负责一个大型项目的测试和验证工作,一边和开发对接测试代码,一边和运维对接“发版”。他发现项目组里的开发和运维两个角色的思维方式差异巨大,一边希望“快快快”,一边希望“稳稳稳”,这让他有点崩溃。

在 2008 Agile Conference 大会上,Patrick 遇到了 Andrew,两个人一拍即合,开始琢磨如何改变这种 Dev 和 Ops 水火不容的现状。

2009 年 10 月,Patrick 通过 Twitter 召集开发工程师和运维工程师在比利时根特市举办了首届“DevOpsDays”大会,开始大规模讨论 Dev 和 Ops 的协作话题。后来为了便于传播“DevOpsDays”被缩写为“DevOps”。

在 2009 年以后,DevOps 开始火遍全球。2010 年,The Agile Admin 博客发表文章《What is DevOps》, 详细阐述了 DevOps 的定义,包括一系列价值观、原则、方法、实践以及对应的工具。

同样是 2010 年,《持续交付》的作者 Jez Humble 出席第二届的 DevOpsDays大会,并做了“持续交付”的演讲。这是非常重要的里程碑,可以说《持续交付》这本书就是 DevOps 的最佳实践。

——摘自《阿里巴巴DevOps实践手册》

因此把 DevOps发展历史分为三个阶段:诞生期、定义期和落地期。

DevOps 的核心理念

DevOps 基于精益、约束理论、丰田生产系统、柔性工程、学习型组织、安全文化、人员优化因素等知识体系,并参考了高信任管理文化、服务型领导、组织变动管理等方法论。把所有这些最可信的原则综合地应用到 IT 价值流中,就产生出 DevOps 这样的成果。

敏捷宣言

敏捷宣言是在 2001 年由软件领域的 17 位顶尖大师共同提出的。他们希望用一套轻量级的价值观和原则体系,来优化那些沉重的软件开发流程(如传统的瀑布式开发模型)和方法论(如统一软件开发过程)。

在敏捷宣言中,一个重要的原则是“频繁地交付可工作的软件,交付周期可以是数星期也可以是数月,推荐更短的周期”,并强调使用小批量任务进行增量发布,而非大规模的作业和瀑布流程的发布。同时,强调建立自组织的小团队,让成员在高度信任的环境中愉悦地工作。在很多实施了敏捷的企业里,生产效率显著提升,敏捷也因此获得了越来越广泛的支持和认可。

持续交付

基于持续构建、测试和集成的开发原则, Jez Humble 和 David Farley 进行了延伸,提出了持续交付,并首次在 2006 年的敏捷大会上做了分享。在持续交付中,“部署流水线”确保代码和基础设施始终处于可部署状态,所有提交到主干的代码都可以安全地部署到生产环境。

精益利润

精益的两个主要原则包括 :坚信前置时间(把原材料转换为成品所需的时间)是提升质量、客户满意度和员工幸福感的最佳度量指标之一 ;小批量任务的交付是缩短前置时间的一个关键因素。

精益原则聚焦在如何通过系统性思考为客户创造价值,系统性思考的范围涉及建立持久目标,拥抱科学思维,创造流和拉动(而非推送)的协作模式,提倡从源头保证质量,以谦逊为导向,尊重流程中的所有个体。

敏捷


最近更新于 2022-07-18 猿小六2022-07-18 发布, 已阅 135 次。