从DevOps务谈敏捷开发.docxVIP

从DevOps业务谈敏捷开发、软件工程及新角色2014-06-08 23:19 林师授 51CTO 字号：T | T本文通过对近期发布的一篇“DevOps是如何伤害一个开发者的”文章不同的观点。综合对IBMRational中国区技术总监孙昕的采访谈谈我对DevOps的一些理解，欢迎提出意见，拍砖。AD： WOT2014课程推荐：实战MSA：用开源软件搭建微服务系统 51CTO主办WOT全球软件技术峰会直减百元优惠活动 抢票进行中！ 说到DevOps，很多人会把开发和运维联系在一起，更准确一点其实就是开发运营的组合。最近在发布关于DevOps的文章时，发现了一个很有趣的现象：在国外，很多博主都纷纷指责“DevOps”运动，越是受欢迎，他们就越是讨厌，甚至排斥。简单的总结一下DevOps让其讨厌的原因：1. 没有时间专心写代码2. 强迫开发人员进入一个庞大的知识领域（这里指就是需要成为一名“全栈”开发者）3. 压力大，任务重，不堪重负事实是否这样呢？其实不然。无论任何事物，存在即合理。再说哪个公司都不会蠢到让一个只会写代码的开发者去做QA，系统管理员或者DBA，所以我认为不能归到“DevOps”里面去。引用DevOps拥护者Jeff Roth的一句话，“专业知识、协作关系与知识共享之间需要找到合适的平衡点，只有这样才能人尽其才、物尽其用。”以上是对近期发布的一篇“DevOps是如何伤害一个开发者的”文章不同的理解。下面综合对IBMRational中国区技术总监孙昕的采访谈谈我对DevOps的一些理解，欢迎提出意见，拍砖。?敏捷开发在刚了解DevOps不久的时候，我很自然的把它和敏捷开发联系在一起，认为它们是集合的关系。在有机会和孙老师聊的时候，他并不认为完全这样，说是集合关系是不完全准确的，不过DevOps可以让敏捷开发做的更好。怎么理解这句话呢，先说说下敏捷开发，了解敏捷的人都知道现在做最多，也是做最好的是Scrum，这是个流派。当整个团队在做到一定的规模后，这时是非常依赖工具的。（因为实施敏捷的时候不完全保证所有人员都能够在一个地方，像那种大规模敏捷的时候，不可能把所有的人都搁置在一个小屋子里面，天天开各种会议。像比较厉害的scrumsof scrums，我是这么理解的）。这里有个问题哈，当Scrum在很大的程度上依赖工具的时候，其实很多问题就出来了。大家都知道Scrum是一个迭代的过程，需要很多周期的迭代，不可能一次就搞定（那就不是Scrum了）。在这个迭代的过程，需要做沟通，做协调，做测试，做部署，发布等等，那么这些事情单单通过工具是否能够完成呢？我觉得很困难。这个时候DevOps在这里能够起到什么作用呢？回到刚才的观点--加速敏捷的进展。因为DevOps可以利用云技术，自动化部署，自动化发布等技术。特别是测试，当敏捷做到一定规模时候，需要跨部门，开发人员可能会很主动，有啥新功能要加进去，运维就不干了，很可能就会说you can you up！其实这个是能够理解的，开发人员把一个软件版本丢给运维人员后，其就会拿该版本产品开始准备将部署上线。这时有个问题出来了，他们需要修改配置文件来适应与开发环境大不相同的真实生产环境。一般情况来说他们是在重复之前在环境中已完成的部署工作；一旦出了问题，他们很可能引入新的漏洞。这就是他们所担心的问题，如果不反复的测试，运维人员肯定不会上线。所以，DevOps的理念正好解决了这个问题，但这仅仅是DevOps很小的一部分。如果再把敏捷往前推，业务管理，生命周期管理，监控管理等等，需要扩张更大的时候，很大程度上都会依赖DevOps。两者之间的关系就是，DevOps可以驱动敏捷加速周期，敏捷也能在某种意义上推广DevOps。传统软件工程大家都应该知道传统的软件工程就是从需求-发布-测试这个过程，也就是只停留在研发这条工具生产线上，所以我们看到的软件工程链条还是比较短的。DevOps概念出来了以后大家慢慢的发现，软件工程现在前端部分已经慢慢全新的领域，前端+传统软件工程+后端，无形的产生了一条很大的产业链，这就是我们现在说的一个全新的软件工程。（PS：据我了解，现在很多企业都在招聘 软件工程（DevOps方向）的岗位，很有趣。）在软件工程的前端方面，也可以称为业务端吧，比如做业务规划。那么产业链的后端负责什么呢？在和孙昕老师聊天的时候他强调的PRE（全称应该是ProductLine Engineer）产品线工程。孙老师还举例说，“像华为等等一些大的企业，它们不仅仅是在做软件，它们所有的嵌入式软件，机械设计，电气设计，软件设计的时候，这些大产品线的本身，其实就是受到很好的工程化管理，从规划到实现，软件在这个部分其实已经占据非常重要的地位，你可以看到PRE当中非常强调的就是后端”。所以在整个软件的大框架下