本文目录

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 发布，已阅 1166 次。