最近老是碰到这个名词，所以想了解一下这个到底是撒玩意？
DevOps（Development和Operations的组合词）是一组过程、方法与系统的统称，用于促进开发（应用程序/软件工程）、技术运营和质量保障（QA）部门之间的沟通、协作与整合。
它是一种重视“软件开发人员（Dev）”和“IT运维技术人员（Ops）”之间沟通合作的文化、运动或惯例。透过自动化“软件交付”和“架构变更”的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。
它的出现是由于软件行业日益清晰地认识到：为了按时交付软件产品和服务，开发和运营工作必须紧密合作。
从定义来看，其实devops就是为了让开发、运维和QA可以高效协作的流程。（可以把DevOps看作开发、技术运营和质量保障（QA）三者的交集。）
DevOps
DevOps对应用程序发布的影响
在很多企业中，应用程序发布是一项涉及多个团队、压力很大、风险很高的活动。然而在具备DevOps能力的组织中，应用程序发布的风险很低，原因如下 [2] ：
（1）减少变更范围
与传统的瀑布模式模型相比，采用敏捷或迭代式开发意味着更频繁的发布、每次发布包含的变化更少。由于部署经常进行，因此每次部署不会对生产系统造成巨大影响，应用程序会以平滑的速率逐渐生长。
（2）加强发布协调
靠强有力的发布协调人来弥合开发与运营之间的技能鸿沟和沟通鸿沟；采用电子数据表、电话会议和企业门户（wiki、sharepoint）等协作工具来确保所有相关人员理解变更的内容并全力合作。
（3）自动化
强大的部署自动化手段确保部署任务的可重复性、减少部署出错的可能性。
与传统开发方法那种大规模的、不频繁的发布（通常以“季度”或“年”为单位）相比，敏捷方法大大提升了发布频率（通常以“天”或“周”为单位）。
实现DevOps需要什么？
硬性要求：工具上的准备
上文提到了工具链的打通，那么工具自然就需要做好准备。现将工具类型及对应的不完全列举整理如下：
代码管理（SCM）：GitHub、GitLab、BitBucket、SubVersion
构建工具：Ant、Gradle、maven
自动部署：Capistrano、CodeDeploy
持续集成（CI）：Bamboo、Hudson、Jenkins
配置管理：Ansible、Chef、Puppet、SaltStack、ScriptRock GuardRail
容器：Docker、LXC、第三方厂商如AWS
编排：Kubernetes、Core、Apache Mesos、DC/OS
服务注册与发现：Zookeeper、etcd、Consul
脚本语言：python、ruby、shell
日志管理：ELK、Logentries
系统监控：Datadog、Graphite、Icinga、Nagios
性能监控：AppDynamics、New Relic、Splunk
压力测试：JMeter、Blaze Meter、loader.io
预警：PagerDuty、pingdom、厂商自带如AWS SNS
HTTP加速器：Varnish
消息总线：ActiveMQ、SQS
应用服务器：Tomcat、JBoss
Web服务器：Apache、Nginx、IIS
数据库：MySQL、Oracle、PostgreSQL等关系型数据库；cassandra、mongoDB、redis等NoSQL数据库
项目管理（PM）：Jira、Asana、Taiga、Trello、Basecamp、Pivotal Tracker
在工具的选择上，需要结合公司业务需求和技术团队情况而定。（注：更多关于工具的详细介绍可以参见此文：51 Best DevOps Tools for #DevOps Engineers）
软性需求：文化和人
DevOps成功与否，公司组织是否利于协作是关键。开发人员和运维人员可以良好沟通互相学习，从而拥有高生产力。并且协作也存在于业务人员与开发人员之间。
出席了2016年伦敦企业级DevOps峰会的ITV公司在2012年就开始落地DevOps，其通用平台主管Clark在接受了InfoQ的采访，在谈及成功时表示，业务人员非常清楚他们希望在最小化可行产品中实现什么，工程师们就按需交付，不做多余工作。
这样，工程师们使用通用的平台（即打通的工具链）得到更好的一致性和更高的质量。此外，DevOps对工程师个人的要求也提高了，很多专家也认为招募到优秀的人才也是一个挑战。
概述
敏捷开发和DevOps都是一种理念。他们的理念相似，都是为了更好更快的发布产品，但又不完全相同。
而CI/CD是实现这两者理念的一种方法。
敏捷开发
前言
传统方式开发前有一份详细的开发文档，程序员照着需求直接敲代码，产品做好了直接部署上线。中间不会有人打扰，需求也不会变。
但是目前的情况是，用户需求和市场都变化太快，就算你前期用户调研的再好，计划书写的再详细，也抵不住市场的变化，说不定产品做出来，用户就不需要了。
所以为了适应市场的发展，我们必须不断提高我们的开发效率，及时跟进用户需求，缩短开发周期。在这种情况下，就有人提出了敏捷开发。
传统开发
传统开发方式的拥护者和敏捷开发方式的拥护者看待软件开发的世界观是不同的。
在传统开发的眼里，软件开发过程是确定的、可测的，只要在一开始努力收集到需要的信息并制定好计划，然后忠实的执行计划就应该可以成功。如果不成功一定是你在一开始就没有做好，没收集到必要的信息，计划做的不好或者执行不到位。然后传统开发方式就试图引入更多的流程，文档，试图让每一步都做到万无一失。
敏捷开发
而在敏捷的眼里世界可不是这样的，敏捷认为在软件开发中，世界是变化的，有很多不确定首先不论哪种开发方式，不过不管什么开发方式前期还是要做足充分的调研和分析，收集足够多的信息。但是我们不是先知，没人能确保自己的预测足够准确，也没人能保证能收集到所有有用的信息。但是可以肯定的是随着开发的进行，我们对会对正在做的东西的认识越来越深刻。因而做一段时间后常常有发现需求有调整，或发现之前的想法不对。另一方面，世界本来就是在快速变化中，尤其是互联网，所以我们也不得不适应这个环境。所以为了适应这个市场的变化，我们要采用敏捷开发。
总结
在传统开发中要做好一个产品，大部分精力都要花在前期
更多调研
更多信息
更多文档
缺点
始终走在市场后面，无法紧跟潮流，做出的产品容易被淘汰。
敏捷开发核心
拥抱变化
快速迭代
下面图的标题是How Spotify builds a product.很好的诠释了敏捷开发的含义
CI/CD
概述
可以把开发工作流程分为以下几个阶段：
编码 -> 构建 -> 集成 -> 测试 -> 交付 -> 部署
正如你在上图中看到，「持续集成（Continuous Integration）」、「持续交付（Continuous Delivery）」和「持续部署（Continuous Deployment）」有着不同的软件自动化交付周期。
持续集成CI（Continuous Integration）
基本概念
持续集成（Continuous Integration）简称CI，持续集成强调开发人员提交了新代码之后，立刻自动的进行构建、（单元）测试。根据测试结果，我们可以确定新代码和原有代码能否正确地集成在一起。
持续集成过程中很重视自动化测试验证结果，对可能出现的一些问题进行预警，以保障最终合并的代码没有问题。
持续交付CD（Continuous Delivery）
基本概念
持续交付在持续集成的基础上，将集成后的代码部署到更贴近真实运行环境的「类生产环境」（production-like environments）中。交付给质量团队或者用户，以供评审。如果评审通过，代码就进入生产阶段。
持续交付并不是指软件每一个改动都要尽快部署到产品环境中，它指的是任何的代码修改都可以在任何时候实施部署。
这里强调的是
手动部署
有部署的能力，但不一定部署
持续部署（Continuous Deployment）
基本概念
持续部署是指当交付的代码通过评审之后，自动部署到生产环境中。持续部署是持续交付的最高阶段。
这里强调
持续部署是自动的
持续部署是持续交付的最高阶段
持续交付（Continuous delivery）与持续部署的关系
有时候，持续交付也与持续部署混淆。持续部署意味着所有的变更都会被自动部署到生产环境中。持续交付意味着所有的变更都可以被部署到生产环境中，但是出于业务考虑，可以选择不部署。如果要实施持续部署，必须先实施持续交付。
持续交付表示的是一种能力
而持续部署则是一种方式
具体实现
整体而言，Jenkins 过去一直是大部分公司的选择，但这个现象正在发生改变，随着公有云服务、Docker，SaaS 的普及，越来越多的企业开始选择在线托管型持续集成系统。
总结
「持续集成（Continuous Integration）」、「持续交付（Continuous Delivery）」和「持续部署（Continuous Deployment）」提供了一个优秀的 DevOps 环境，对于整个团队来说，好处与挑战并行。无论如何，频繁部署、快速交付以及开发测试流程自动化都将成为未来软件工程的重要组成部分。
DevOps（开发与运维 – Development and Operations）
产生背景
DevOps是Development和Operations缩写，现在市场需求和技术变化都非常快，为了配合市场的需求，开发周期就要变短（但是软件质量不能因为这个原因降低），比如说某些APP可能每周就要更新一次，所以说为了跟上市场的变化，势必就要缩短开发周期，但是传统的开发过程中与运维相关的部分比如测试，发布，部署都很花时间，所以往往开发人员和运维人员之间有着很深的隔阂，并且两者沟通效率低，为了解决这个问题，使之能够更专注于开发。就有人提出了DevOps这理念。
DevOps简单的说就是为了打破传统开发和运维之间的隔阂与低效，在保证产品质量的前提下实现更自动化、更高效的协作与产品的交付。
DevOps是什么
DevOps（Development和Operations的组合词）是一种重视“软件开发人员（Dev）”和“IT运维技术人员（Ops）”之间沟通合作的文化、运动或惯例。通过自动化“软件交付”和“架构变更”的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。
具体来说，就是在软件交付和部署过程中的提高沟通与协作的效率，旨在更快、更可靠的的发布更高质量的产品。
我们可以列举下DevOps是干啥的。
DevOps是一组过程、方法与系统的统称。用于促进开发、运维和质量保障部门之间的沟通、协作与整合。
DevOps是一种文化转变，打破了以往开发和运维之间的隔阂，或者说是一个鼓励更好地交流和协作（即团队合作）以便于更快地构建可靠性更高、质量更好的软件的运动。
DevOps 是一种工程模式，本质上是一种分工，通过对开发、运维、测试，配管等角色职责的分工，实现工程效率最大化，进而满足业务的需求。
DevOps是一种能力，具备此能力的团队可以高质量、快速的交付软件产品或服务。
DevOps与传统开发方式区别
传统的开发方式是线性的，开发与运维之间存在隔阂而且沟通效率低下。而DevOps使开发与运维的流程形成了一个闭环，打破了隔阂，各部门协作更紧密，提高了协作效率。
DevOps好处
依托自动化工具把开发、测试、发布、部署的过程整合，实现高度自动化与高效交付。
在保证产品质量的前提下快速、频繁地发布产品。
能够即使获得用户反馈，并快速响应。
最大限度地减少风险，降低代码的出错率。
高质量的软件发布标准。整个交付过程标准化、可重复、可靠。
整个交付过程进度可视化，方便团队人员了解并控制项目进度。
团队协作更高效。
为什么DevOps姗姗来迟
容器技术开始成熟，特别是docker技术的大行其道。
微服务架构技术的广泛使用。
微服务是支撑DevOps方法的手段，传统开发是在一个服务器里面，把各种元素装在一起组合成一个程序，但微服务是每一个服务是一个单独的单元，可以部署在不同的服务器上，通过SOA的方法，把它连接起来，再提供整个功能。
微服务是由一个个团队组成，每团队有自己的服务，做好后，可以独立的进行测试、开发、部署，然后整个应用组合到一起。
敏捷开发流程的深入人心。
诸如Scrum, Agile, Kanban等敏捷方式被团队广泛使用，TDD、BDD、DDD这些测试驱动设计、行为驱动设计、域驱动设计等设计方式的采纳，CI和CD这些持续集成和持续部署等方式的实施，这些都是对DevOps的强烈需求。
DevOps带来的变革
角色分工：打破传统团队隔阂，让开发、运维紧密结合，高效协作
研发：专注研发、高度敏捷、持续集成
产品交付：高质量、快速、频繁、自动化、持续交付
具体落地
简单的说，DevOps=团队文化+流程+工具
团队文化的意思很简单就是你的团队要知道并认可DevOps理念
然后就要通过具体的流程和工具来实现这个理念。
DevOps工具
简单列举下常见的DevOps工具
