DevOps是什么？

DevOps理念诞生于2009年。

”IT组织的存在就是为了交付业务向其客户交付商业价值所需要的能力。业务要求IT组织进行优化，要更加敏捷，适应变化，更具有响应力，利用更少的资源做更多的事情，更加高效，提高产能，更快速、更高质的交付，针对市场灵活应变，加速竞争，遵守不断变化的监管与合规制度以及，当前也要缩减开支。“

DevOps存在的第一性原理：敏捷或速度的诉求。

2020年维基百科上最新的DevOps定义（一直在不断修正，业界看待DevOps的观点也在变化）：

DevOps（Development和Operations的组合词）是一种重视“软件开发人员（Dev）”和“IT运维技术人员（Ops）”之间沟通合作的文化、运动或惯例。透过自动化“软件交付”和“架构变更”的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。

说明：13年和16年的定义可参考书中前言部分介绍，也可以参考下面链接中的内容。https://blog.csdn.net/chengqiuming/article/details/81709336

DevOps两项核心实践

持续集成（已经成为敏捷的核心竞争力）和持续交付。都聚焦于周期时间最小化。

周期时间：从需求或者用户故事开始到把功能交付到客户手中，或者至少完成集成、测试并已部署到客户机做好准备的时间

交付生命周期中的所有利益相关者都需要进行更好的沟通与协作，而不仅是开发和运维之间。

持续集成

持续集成是指按固定节奏（定期，至少每天）进行集成的过程，它是敏捷开发的原则之一。使开发人员得以将其软件组件与内、外部的其他开发人员所开发的组件进行定期集成（主要是指代码的集成），以便尽早识别风险。

只做持续集成构建，不做集成测试去验证及识别缺陷，只能说具备持续集成构建能力，却没有其他能力。

持续交付

持续交付：    可通过交付流水线实现持续交付自动化。持续交付不是一个流程，而是随时根据需要部署到任何环境的能力。它的核心实践是自动化部署。

持续交付并不意味这每一次变化都要尽快部署到生产环境，而是意味着每一次变化都是随时可以部署的。所以具有持续部署的能力比实际持续地生产上线更为重要。

「持续集成」帮助产品以稳定的节奏构建，「持续交付」让这些构建快速地交付至流水线中的其他环境。

除核心实践外的支持实践

1、基础设施即代码：将上线一个新虚拟环境或一个环境的新版本，变成执行脚本的过程（即：使用代码来定义、版本化和维护完整环境）。比如：Ansible就是一种用来获取及管理基础设施即代码的自动化架构。运维人员需要管理的不是生命周期很长的独立服务器，而是大量的临时服务器，按需进行环境的提供和释放。

2、持续反馈：是实现持续改进和提高质量的必要条件，也是戴明PDCA循环的核心。没有持续反馈，持续集成和持续交付几乎没有任何意义。

持续测试和持续监控来实现持续反馈。

持续测试：单元测试、功能测试、性能测试、集成测试、安全测试、用户验收测试等。

持续监控：需要获取并分析的4个方面的衡量指标（应用性能、系统性能、应用用户行为、用户情绪）等。注意：数据能用才有价值，好的数据，能更好的驱动持续改进。

3、持续业务计划

改实践关注业务线及其计划流程。利用精益思想，加快业务需求的响应周期。可参考：精益创业。

4、协同开发

确保具有大型分布式团队的组织实现跨职能部门操作人员以及跨仓筒团队之间的协作与可见性是必不可少的。可通过跨交付流水线的两个功能来实现（比如：提供给操作人员的访问权限和可见性）

“前移”

概念来源于精益。基本思想是将生命周期中影响质量的任务尽可能提前，以此来提高质量。

1、测试前移——“尽早测试，频繁测试”，其中，集成测试前移的意义最大。

2、运维前移

运维人员尽早参与，有助于确保开发-测试期间所部署的开发及测试类生产环境确实与真正的生产环境类似。

运维人员指责前移，角色从执行者变为服务供应商。开发人员、测试人员及其他运维人员，利用运维团队提供并管理的自助服务，根据需要提供、配置并释放服务器实例。

持续改进

在DevOps背景下，学习型组织是要不断地从刚刚交付的内容中学习并持续改进。

DevOps的文化运动

DevOps包括实施和文化两部分，只单独实施DevOps实践无法培养出文化。只有克服了组织内根深蒂固的文化惰性，才能成功实施DevOps文化。其中，文化惰性可以从三方面来克服：（1）可见行：一起共事的团队或人员知道彼此拿到的构建交付物之前都做过什么；

（2）有效沟通：实时、面对面沟通比邮件、计划、文档更为有效；

（3）通用衡量标准：开发、测试、运维，每一个人都必须对生产上线部署负责，应该需要相同或类似的成功衡量标准，让大家为同一个目标而工作。

小结

对DevOps的概念和如何实施的问题上，目前并没有达成共识。正确的答案确是“视情况而定”，因为这取决于为之奋斗的业务目标、实践当前的成熟度、足额只能够承受的变化速度等。

其它可参考的文章链接：https://blog.csdn.net/GitChat/article/details/78263301

《DevOps现状调查报告》

《持续交付》-Jez Humble