DevOps 简介
作者：尹正杰
版权声明：原创作品，谢绝转载！否则将追究法律责任。
DevOps是Development和Operations的组合，也就是开发和运维的简写。那句话怎么说来着，DevOps的价值应由业务价值的产出来评判，而不是根据IT项目范围和IT成果来评判。
一.DevOps概述
1>.什么是DevOps
企业往往同时拥有交互型系统（SoE）和记录型系统（SoR）。SoE系统关注的是速度，SoR系统关注的是业务连续性。问题是当SoE频繁变更的时候，如何保障SoR的业务连续性呢？Gartner公司把这称为双峰挑战（Bimodal challenge）。 DevOps是针对企业中的研发人员，运维人员和测试人员的工作理念，是他们在应用开发，代码部署和质量测试等整条生命周期中协同和沟通的最佳实践，DevOps枪带哦整个组织的何做以及较父和基础设施变更的自动化，从而实现持续集成，持续部署和持续交付。 DevOps的四大平台:
代码托管:
GitHub，GitLib,SVN,码云等,
项目管理:
jira，Gerrit权限审计。
运维平台:
腾讯蓝鲸开源平台。
持续交付:
Jenkins开源软件。
一般情况下，软件测试分为以下几个步骤:
开发测试环境:
一般是由Dev用自己的测试环境进行测试，测试通过后由运维将具体分支代码打包并交给测试。
预发布测试环境:
由QA进行测试，找到Bug后提交到相应bug追踪平台，再由Dev进行修复Bug，经过多轮测试后，经各层领导确认后开始灰度发布阶段。
灰度发布:
只对线上版本的部分用户进行测试，如果你玩过英雄联盟(LOL)的话一定知道LOL进行升级的时候，有的时候会对部分大区进行维护，其实这就有种类似于灰度发布的应用场景。
灰度发布的优点就是用部分生产环境进行测试，如果运行一段时间没有问题后就会批量升级，如果测试不成功则随时可以回退到之前的版本。
生产发布环境:
灰度发布只会影响到一部分用户，如果灰度测试一段时间没有问题时就会对剩下的为升级的代码按规模进行批量升级或者分批次升级
我们知道类似于百度，阿里，腾讯这样的大型互联网公司，在全国各地应该都有自己的机房，在进行代码升级时可能会按照不同的机房进行升级。
2>.为什么要推广DevOps
DevOps强调团队协作，相互协助，持续发展，然而传统的模式是开发人员只顾开发程序，运维只负责基础环境管理和代码部署及监控等，其并不是为了一个共同的目标而共同实现最终的目的。
而DevOps则实现团队作战，即无论是开发，运维还是测试，都是为了最终的代码发布，持续部署和业务稳定而付出各自的努力，从而实现产品设计，开发，测试和部署的良性循环，实现产品的最终持续交付。
二.传统运维技术团队对比DevOps技术团队
1>.传统运维
一旦线上出现故障，基本上都是运维人员第一时间告知别人哈，如果让别人通知运维那估计领导就得找你谈话了。
哈哈哈~下图太能反应运维工作中需要和各部门的人打交道。
2>.DevOps
如下图所示，形成了一个良性循环，也有人称之为"戴明环"。运维(OP),开发(DEV),测试(QA)形成了一条纽带。
对一个或多个产品进行循环执行PLAN,CODE,BUILD,TEST,RELEASE,DEPLOY,OPERATE,MONITOR流程，从而对一个或多个产品进行多次打磨，而后为客户提供一个更好的产品。
三.DevOps相关术语
1>.持续集成(Continuous Integration，简称CI)
持续集成是指多名开发者在开发不同功能代码的过程当中，可以频繁的将代码合并到一起并切换相互不影响工作。
2>.持续部署(Continuous Deployment，简称CD)
是基于某种工具或平台实现代码自动化的构建，测试和部署到线上环境实现交付高质量的产品，持续部署在某种程度上代表了一个开发团队的更新迭代速率。
3>.持续交付(Continuous Delivery)
持续交付时在持续部署的基础之上，将产品交付到线上环境，因此持续交付是产品价值的一种交付，是产品价值的一种盈利的实现。
四.常见的持续集成开源工具
1>.常见的部署方式
开发自己上传:
最原始的方案
开发给运维手动上传:
运维自己手动部署
运维使用脚本部署:
半自动化
结合webweb界面一键部署:
自动化
2>.常见的持续集成开源工具
在公司的服务器安装某种程序，该程序用于按照特定格式和方式记录和保存公司多名开发人员不定期提交的源代码，且后期开源按照某种标记及方式对用户提交的数据进行还原。具有该程序的功能常见的解决方案有以下几种:
Concurrent Version System(简称CVS):
早期集中式版本控制系统，先已基本淘汰。会出现数据提交后不完整的情况。
Subversion(简称SVN):
集中式版本控制系统，2000年开始开发，目标就是代替CVS集中式管理，依赖于网络，一台服务器几种管理目前依然有部分公司在使用。
Gitlib:
分布式版本控制系统，linus在1991年创建了开源的Linux内核，从此Linux便不断快速发展，不过Linux的壮大式离不开全世界的开发者的参与，这么多人在世界各地的Linux编写代码，那Linux内核的代码是如何管理的呢？
事实是，2002年世界各地志愿者把源代码文件通过diff的方式发给linus，然后由Linux本人通过手工方式合并代码！你也许会想，为什么linus不把Linux代码放到版本控制系统里呢？不是有CVS,SVN这些免费的版本控制系统吗？
因为linus坚定的反对CVS和SVN，这些集中式的版本控制系统不但速度慢，且必须联网才能使用，但是也有一些商用的版本控制系统，虽然比CVS,SVN好用，但那是付费的，和Linux的开源精神不符。
不过，到了2002年，Linux系统已经发展了十年了，代码库之大让linus很纳继续通过手动方式管理了，社区的弟兄们也对这种方式表达了强烈不满，于是linus选择了一个商业的版本控制系统BitKeeper。
BitKeeper的东家BitMover公司处于人道主义精神，授权linux社区免费试用这个版本控制系统，但是安定团结的大好局面在2005年被打破了。
原因是linux社区牛人聚集，不免沾染了梁山好汉的江湖习气，开发Samba的Andrew试图破解BitKeeper的协议(正安的其实也不止他一个)，被BitMover公司发现了(监控工作做的不错！),于是BitMover公司怒了，要收回linux社区的免费使用权。
这时候其实linus可以向BitMover公司道个歉，保证以后严格管教弟兄们，但这是不可能的，而且实际情况是Linus自己花费了两周时间用C写了一个分布式版本控制系统，也就是Git！
一个月内，Linux内核的源代码已经由Git管理了！牛是怎么定义的呢？大家可以体会一下。
而后Git迅速成为最牛下的分布式版本控制系统，尤其是2008年，GitHub网站上线了，它为开源项目免费提供Git存储，无数开源项目开始迁移至GitHub，包括JQuary，Php,Ruby等等。
五.版本控制系统分类
1>.集中式版本控制系统
任何的提交和回滚都依赖于连接服务器SVN服务器，存在单点故障。
2>.分布式版本控制系统
Git在每个用户都有一个完整的服务器，然后再一个中央服务器，用户开源先将代码提交到本地，没有网络也开源先提交到本地，然后再有网络的时候再提交到中央服务器，这样就大大方便了开发者。
而相比CVS和SVN都是集中式的版本控制系统，工作的时候需要先从中央服务器获取最新的代码，改完之后需要提交，如果是一个比较大的文件则需要足够快的网络才能快速提交完成。
而使用分布式的版本控制系统，每个用户都是一个完整的版本库，即使没有中央服务器也可以提交代码或者回滚，最终再把改好的代码提交至中央服务器进行合并即可。
六.DevOps的的知识体系
当实施DevOps时，我们将从很多知识源、方法论、实践案例和工具中去选择参考。DevOps主要由以下的三大支柱和一个基础组成。
内容摘自Koichiro(Luke) Toda Nobuyuki Mitsui所写的<<DevOps Master 白皮书 企业DevOps的成功之路>>,推荐咱们运维人员去看一下。还有一个不错的书叫<< SRE Google运维解密>>，感兴趣的小伙伴可自行查阅相关资料。
1>.规范敏捷（Disciplined Agile）
一支训练有素的敏捷开发团队是成功实施DevOps的关键。
规范敏捷意味着： 速度稳定（Stabilized Velocity） 适应变化（Adaptability for change） 总是能发布优质的无错误代码（Always release high quality bug free code）
在IT服务生命周期中，越来越频繁和快速发布的开发速度应取决于业务变更的频度。工作质量是最重要的，需要将工作分割为小任务来进行支持。 Ji-Koutei-Kanketsu（JKK）概念，认为100%的完成每个条目，是有助于保持高质量工作的。而“做完了”（Done）与“结束了”（Completion）的这些概念，对每个人来说都必须定义清楚。
使产品负责人可能改变他/她的任务的，未必一定是对待办项（Product Backlog）的管理，也可能是新的IT服务计划，在丰田，这工作是由首席工程师来完成的。
2>.持续交付（Continuous Delivery）
持续交付指的是实现自动应用程序的构建、部署、测试和发布的流程。
一个关键的关注点是测试，如验收测试和性能测试等。TPI NEXT®（测试流程优化）可以用于提高这个过程的成熟度。
每个组织都会有各自不同部署流管线（Pipeline），因发布软件的价值流而异。
一个关键的成功因素是为IT服务建立一个单一的部署管线。
3>.IT服务管理（IT service management）
当技术成为大多数业务流程的核心环节时，IT服务的连续性和高可用性是业务存亡的关键因素。这可以通过引入降低风险措施和恢复方案来实现。就像IT服务管理所有要素都提及的，只有成功实现服务的连续性才能实现对高层的承诺，并支持组织的所有成员。对于保持有效性而言，持续维护其可恢复能力是最基本的前提条件。服务连续性是服务保障的必要组成部分。如果服务无法按照业务的要求保持连续性或恢复，那么业务将无法实现所承诺的价值。服务将无法被提供，从而失去持续的功效。
传统的IT服务管理（ITSM）最佳实践，比如ITIL看起来很繁琐，不匹配DevOps中所倡导的快速流程。有必要考虑一下如何降低管理工作量。
基于DevOps去重新调整ITSM是有必要的，创建轻量级的只包含所最少必要信息（Minimum Required Information，MRI）的，严格聚焦于业务持续性的轻量ITSM。每个组织的MRI设置取决于他们的业务。
4>.以TPS（精益管理Lean）理念为基础
建立一个流水线式的IT服务供应链并不容易，因为有许多项目要改变现有熟悉的开发周期和方法论，你很有必要观念上做改变。
TPS的概念包括JIT和自动化，TPS可以帮助做到以下环节： JIT意味着要建立一个流水线式的单件流（one-piece flow）的供应链。而自动化意味着尽可能实现自动化并且当生产过程出现缺陷时能停止整个过程。 这个过程需要设计并且员工也需要充分理解这两个概念。 另一个关键问题是开发和运维的生命周期。需要通过敏捷的方法改变工作方式，包括开发和运维之间每周或每天的信息同步。
5>.DevOps的的知识体系图
下图展示了DevOps的的知识体系。
