1 简介

1.1 DevOps概述

最初是瀑布模型，后来是敏捷开发，现在是DevOps，这是现代开发人员构建出色的产品的技术路线。
DevOps早在 2009 年就已经被提出来了。
单纯从字面上来理解，DevOps 是Dev（开发人员）+Ops（运维人员），虽然名字来源于开发和运维的缩写，但DevOps并不是简单的就是开发加运维。
DevOps 所涵盖的角色范围会更广：除了开发、测试、运维还会涉及到项目经理、产品经理，甚至和销售、市场等各个部门，跨职能部门互相合作，完成某一项目或任务。
DevOps是通过工具，自动化，来达到这种通过工具链与持续集成、交付、反馈、优化进行端到端整合，完成无缝的跨团队、跨系统协作。即DevOps是一种协作方式。

在这里插入图片描述

1.2 DevOps推崇文化

尊重（Respect）
正视失败（Healthy attitude about failure）
不埋怨（Avoiding Blame）
精益求精
工程质量文化
快速验证文化
客户导向文化

1.3 CI/CD

CI/CD是DevOps最佳实践手段。
CI / CD的采用改变了开发人员和测试人员如何发布软件。
在这里插入图片描述
最初是瀑布模型，后来是敏捷开发，现在是DevOps，这是现代开发人员构建出色的产品的技术路线。随着DevOps的兴起，出现了持续集成（Continuous Integration）、持续交付（Continuous Delivery）、持续部署（Continuous Deployment）的新方法。传统的软件开发和交付方法正在迅速变得过时。从历史上看，在敏捷时代，大多数公司会每月，每季度，每两年甚至每年发布部署/发布软件。然而，现在，在DevOps时代，每周，每天，甚至每天多次是常态。当SaaS正在占领世界时，尤其如此，您可以轻松地动态更新应用程序，而无需强迫客户下载新组件。很多时候，他们甚至都不会意识到正在发生变化。开发团队通过软件交付流水线（Pipeline）实现自动化，以缩短交付周期，大多数团队都有自动化流程来检查代码并部署到新环境。

1.3.1 CI(Continuous integration)持续集成

介绍

CI(Continuous integration)即持续集成。在CI环境中，开发人员将会频繁地向主干提交代码。这些新提交的代码在最终合并到主干前，需要经过编译和自动化测试流进行验证。
在这里插入图片描述

要求

团队需要为每个新功能、代码改进、或者问题修复创建自动化测试用例。
你需要一个持续集成服务器，它可以监控代码提交情况，对每个新的提交进行自动化测试。
研发团队需要尽可能快的提交代码，至少每天一次提交。

优点

通过自动化测试可以提早拿到回归测试的结果，避免将一些问题提交到交付生产中。
发布编译将会更加容易，因为合并之初已经将所有问题都规避了。
减少工作问题切换，研发可以很快获得构建失败的消息，在开始下一个任务之前就可以很快解决。
测试成本大幅降低，你的CI服务器可以在几秒钟之内运行上百条测试。
你的QA团队花费在测试上面的时间会大幅缩短，将会更加侧重于质量文化的提升上面。

1.3.2 CD(Continuous Delivery)持续交付

介绍

CD(Continuous Delivery)即持续交付。它可以让软件产品的产出过程在一个短周期内完成，以保证软件可以稳定、持续的保持在随时可以释出的状况。它的目标在于让软件的建置、测试与释出变得更快以及更频繁。这种方式可以减少软件开发的成本与时间，减少风险。
在这里插入图片描述

要求

你需要有强大的持续集成组件和足够多的测试项可以满足你代码的需求。
部署需要自动化。触发是手动的，但是部署一旦开始，就不能人为干预。
你的团队可能需要接受特性开关，没有完成的功能模块不会影响到线上产品。

优点

发布频率更快，因为你不需要停下来等待发布。每一处提交都会自动触发发布流。
在小批量发布的时候，风险降低了，发现问题也可以很轻松的修复。
客户每天都可以看到我们的持续改进和提升，而不是每个月或者每季度，或者每年。

1.3.3 CD(Continuous Deployment)持续部署

介绍

CD(Continuous Deployment)即持续部署。在CD环境中，通过自动化的构建、测试和部署循环来快速交付高质量的产品。某种程度上代表了一个开发团队工程化的程度，任何修改通过了所有已有的工作流就会直接和客户见面，只有当一个修改在工作流中构建失败才能阻止它部署到产品线。
持续部署是一个很优秀的方式，可以加速与客户的反馈循环，但是会给团队带来压力，因为不再有“发布日”了。开发人员可以专注于构建软件，他们看到他们的修改在他们完成工作后几分钟就上线了。