一、什么是DevOps

1、 DevOps概述

DevOps，即Development and Operations，是一组过程、方法与系统的统称，用于促进软件开发、运维和质量保障部门之间的沟通、协作与整合。DevOps的出现是由于软件行业日益清晰的认识到：为了按时交付软件产品和服务，开发和运维工作必须紧密合作。DevOps可看作开发、运维和质量保障（QA）三者的交集。

DevOps运动源自于提高IT服务交付敏捷性的需要，早期出现在许多大型公有云服务提供商中，并被其认可。支撑DevOps的理念基础是敏捷宣言，它强调人（和文化），致力于改善开发和运维团队之间的协作。从生命周期的角度来看，DevOps的实施者也试图更好的利用技术，尤其是自动化工具，来支撑越来越多的可编程的动态的基础设施。
在这里插入图片描述

2、 DevOps的技术实践基本元素

2.1 配置管理

软件配置管理的核心功能是版本控制。版本控制系统是一种软件，可以管理代码的所有版本并跟踪代码中的更改。

2.1.1 源码管理

分布式Git VS 集中式SVN
版本控制系统分为集中式和分布式两种工作模式，Git和SVN是最为广泛被使用的代表，Git由于其诸多特点，更适合DevOps。

安全性——Git是分布式，而SVN是集中式，存在单点故障风险。
分支功能——Git分支功能强大，便于查询和追溯分支间的提交历史，且支持双向合并。
发布控制——Git发布控制相当灵活，而SVN并没有明确的发布控制配置。
开发审核——Git支持团队成员自建分支和版本库，从提交说明、代码规范等方面对提交逐一审核；而SVN则不具备这些功能。
合并支持——Git基于DAG（有向非环图）的设计比SVN的线性提交提供更好的合并追踪，避免不必要的冲突，提高了工作效率。
存储方式——Git把内容按元数据方式存储，而SVN是按文件。

2.1.2 包文件管理

包文件通常不放在源码库中管理，而是使用专门的包文件仓库（repository）进行存储，并配合包文件依赖管理工具（Maven、npm、Ivy等）进行使用。包文件仓库可以大致分为本地仓库、私服仓库、中央仓库三种。本地仓库是指开发者个人PC中包文件的存储；私服仓库通常是企业为了提升包文件使用性能而搭建的局域网内共用的包文件仓库，通常使用开源的Nexus、artifactory等工具搭建；中央仓库是指开源包文件的共享社区。

开发人员对包文件的使用集中在下载、搜索、发布上传几个操作上。开发和构建时，开发人员通过包依赖管理工具定义好需要使用的私有及开源包文件，在构建或运行时自动从私服仓库或开源中央仓库中下载依赖包文件来提升开发效率。

2.2 持续集成（Continuous Integration）

持续集成（CI）是一种软件开发实践，即团队的成员经常集成他们的工作，通常每个成员每天至少集成一次——这导致每天发生多次集成。每次集成都通过自动化的构建（包括测试）来验证，从而尽快的检测出集成错误。

2.3 持续交付（Continuous Delivery）

持续交付（CD）是从构建环境到生产环境的构建、测试、配置和部署的过程。

持续交付是一种软件工程手法，让软件产品的产出过程在一个短周期内完成，以保证软件可以稳定、持续的保持在随时可以发布的状况。它的目标在于让软件的构建、测试与发布变得更快以及更频繁。这种方式可以减少软件开发的成本与时间，减少风险。

2.4 基础设施即代码（Infrastructure as Code）

作为代码的基础设施（IaC）是描述性模型中的基础设施（网络、虚拟机、负载平衡器和连接拓扑）的管理，使用与DevOps团队用于源代码相同的版本。与同一源代码生成相同二进制文件的原则一样，IaC模型在每次应用时都会生成相同的环境。

IaC是DevOps的关键实践，与持续交付结合使用。
在这里插入图片描述

3、 DevOps转型的研发工具链（快速交付）

快速交付的关键是“自动”与“可靠”。自动是一个很宽泛的词汇，在软件交付中代表着测试自动化、交付自动化、运维自动化等，而可靠讲的是每一次交付要保证是当前的交付是稳定的或可回滚到稳定版本的。

为了解决“自动”与“可靠”的问题，敏捷开发鼻祖Martin Fowler提出了持续集成与持续交付的概念，它所描述的软件开发，是从原始需求识别到最终产品部署到生产环境这个过程中，需求以小批量形式在团队的各个角色间顺畅流动，能够以较短的周期完成需求的小粒度频繁交付。频繁的交付周期带来了更迅速的对软件的反馈，并且在这个过程中，需求分析、产品的用户体验和交互设计、开发、测试、运维等角色密切协作，相比于传统的瀑布式软件团队，更少浪费。通过这种小步快跑的方式，将小功能快速迭代、验证、交付，通过自动化的工具，将测试、部署、运维自动化，减少需求在软件生命周期中流动的时间。
在这里插入图片描述