7月份新入职了一家公司，新公司没有运维岗位，这里的运维都会开发（好厉害），称为devops。我之前对devops的认识停留在Jenkins自动发布工具上（一度认为devops就是Jenkins自动触发编译打包、发布部署流程），本着补补课的目的，去某知乎逛了逛
devops诞生的背景
诞生的背景：
交付步骤1.0
一个软件从零开始到最终交付大概包括一下几个阶段：规划、编码、构建、测试、部署、维护
最初程序都是简单的，工作量不大，程序员有一个人可以完成所有阶段的工作。（现在也有这种情况，只不过大部分都是程序员们自己闲暇时光自己玩的项目）
随着软件产业的发展壮大，软件的规模也在逐渐变得庞大。软件的复杂度不断攀升。一个人已经支撑不住了，开始出现了更细致的分工。
交付步骤2.0
软件开发工程师、测试工程师、运维工程师等岗位被细分出来。
此时的软件交付步骤分为：开发、测试、部署
交付步骤3.0
因为需求的变更迅速、临时需求的增加，导致开发时间紧张，不能等代码全部写完后一起提交，并且这种方式很可能导致最后提交时兼容性问题，产生冲突。修复的并不比重写好受太多。。。
解决这种局面的方法是：每写完一个小的功能点就提交，进行合并代码进行接下来的测试、部署阶段等。
devops出现的必然性：
每次写完个小功能点就提交会让开发、测试、运维之间合作更加紧密。并且每次提交动作的发生，会触发测试和运维的工作，这本身就是有一定的流程，所以可以进行自动的工具来代替人完成。
并且开发和运维经常会发生"扯皮、甩锅"，为了解决合作之间的问题，需要运维懂一些开发知识，开发懂一些运维知识。使用自动化工具来规范这一流程显得十分必要，可以解决扯皮的问题，也减轻了测试、运维的工作量，使得开发人员的代码更规范。
devops一词出现的过程：
2008年8月，在加拿大多伦多举办的敏捷大会上，Anrew Shafer和Patrick 对"敏捷基础设施"进行了讨论，其中包含如何打破Dev和Ops的隔阂。
2009年6月，Flickr分享了他们每天超过10次的部署经验，引起了很大的反响。
2009年10月，在比利时根特举办了第一届DevopsDays的活动，后来因为推特140字符的限制，大家在讨论时去掉了Days，于是"Devops"一词诞生。
devops一词的定义：
在这里我就不粘贴百度百科、维基百科的定义了，我查看知乎，看到有意思的观点入戏：
①方法：有人定义devops是方法论
②工具：有人定义devops是借助一系列工具来完成自动测试发布等流程
③哲学：devops是一种哲学
我个人因为从业时间不长，对devops的认识更是短浅，暂时同意方法和工具层面的定义。
个人暂时认为devops是一个借助工具、平台来实现促进从开发提交代码到测、部署等一系列流程的自动化，减少人工的干预以及方便的管理。
关于devops自己的看法
浅显的谈devops作用
是运维，但不是单纯的运维（不会开发的运维不是好厨子）
是测试，但是不是但单纯的测试
是开发，但不是单纯的开发。
借助一系列符合公司现状的工具来形成敏捷开发交付的规范，促进公司软件产业的发展，应该是就是devops的意义吧。
未来发展趋势
个人认为devops岗位的设定是公司基于业务发展的需求，推动敏捷开发质量与速度。此岗位设置开发、测试、运维等岗位。
我在上家公司中遇到过一个从开发到测试到产品经理的大佬，认为对开发、测试、运维都有涉及的人员对此了解可能更深刻。
因为软件产业的架构越来越复杂，公司速度发展越来越快，此岗位会越来越多，并对从业者的要求也会越来越高，设立此岗位的公司绝非是小公司。
未来发展趋势也会比较好。
