devops是谁提出来的,devops到底是什么
DevOps这不是传说！
DevOps这不是传说！7月12日，VMware网络云博俱乐部，iPhone 4S，iPad和Xbox 360等着你。点击了解详情。
维基百科说：“DevOps是软件开发、运营和质量保证部门之间沟通、协作和集成所采用的流程、方法和系统的集合。人们及时生产软件产品或服务以满足某个商业目标，这是对开发、运营和维护之间相互依赖关系的新理解。这正好体现了精益管理中的顾客价值原则，即从顾客的角度出发，确定从设计到生产、交付的全过程，从而实现顾客需求的最大化满足。我们也可以把DevOps看作是一种能力。在缺乏这种能力的组织中，在开发与操作和维护之间存在信息“鸿沟”。
如何获得这种能力？重点有两个：一是全局观：从软件交付的全局出发，加强之前角色之间的合作；二、自动化：人机交互即人工操作。应该选择那些支持脚本、不需要人机交互界面的功能强大的管理工具，比如各种版本控制的脚本、Nagios这样的基础设施监控工具、Puppet、Chef这样的基础设施配置管理工具。
有人评论说：‘就目前国内情况来看，DevOps还很远。可能只有行业内的顶尖公司，或者新成立的公司才会尝试这个。大多数企业还没有开始敏捷推广，传统的障碍将使敏捷推广的进程遥遥无期。DevOps真的离我们那么远吗？DevOps应该从哪里开始？
首先，让数据说话。我们来看看百度一条产品线在半年内的变化。首先要解释两个百度术语。“测试”是指在项目开发完成后，正式启动前，将项目提交给测试小组进行测试的活动。对于客户来说，‘提’这个动作本身并没有增加什么价值，只是需要一些时间。“上线”是指项目经验证合格后部署到服务器的过程，包括“上线申请”和“实际部署”。可能这两个活动在不同的公司名称不一样，但是在软件生命周期中，无论‘测试’和‘上线’需要多长时间，大家可能都不会感到意外。下面两张图是这条产品线改进后的对比数据。
从图中不难看出，提升和上线部署的效率有了很大的提高。像百度这样的互联网公司，产品线不计其数，几乎每个产品线每周都有新功能部署。单从这两个数据来看，好处可想而知。那么，半年前是什么情况呢？
二。流程建模既然DevOps关注的是价值交付的全过程，那我们就来看看这个产品线常见的交付流程。
对于单个项目来说，一般是典型的瀑布式开发过程。首先收集整理需求，然后写MRD(营销需求文档)或者总体设计，然后评审。如果涉及多个模块，每个模块的开发人员会对各自的模块进行详细设计，给出大致的开发方案，并约定联调时间点。之后，开发人员会从主干中拉出项目分支，并在其上进行开发。到了最后的调试点，几个开发人员会把代码放在一起调试。调用完成后，开发人员再次申请测试。测试人员收到测试申请表后，会进行测试，记录Bug，通知开发人员修复，直到质量达标。之后由开发人员填写在线申请单，经运维人员确认后，运维人员进行在线部署操作。如图所示。
开发的复杂性还在于这个产品线中有很多并行的项目。为了避免相互干扰可能造成的冲突，每个项目在启动后都会在主干上再次拔出分支，然后在上线前合并。如下图所示。
此外，并行项目非常多，每个开发人员会同时参与不同阶段的几个项目。虽然那些周期长的项目会被分解成多次迭代，但是每次迭代的开发过程都是一样的，只是最后只有一次。
概括起来，突出的问题如下：
同一角色的多人合作发展；各角色部门之间的协作针对各自的产品，如MRD、产品代码、测试用例、在线操作单等；基于人机交互的内部流程管理平台。三。发现浪费从精益思维开始，为了尽快传递价值，首先要找出整个流程中的浪费，并加以消除，从而提高流程的效率，让‘一个想法从提出到实现’在最短的时间内完成。那么，浪费在哪里呢？
合并后，一些不必要的多分支开发出现问题的风险很高。同一个模块的代码可能要在多个项目中修改，每次代码最后合并都会出现一些问题，非常痛苦，尤其是修改比较大的时候，需要很长时间的合并和修复。拖延发现问题的时间。每个开发人员在开发之前都会将需求分解成多个技术任务。因此，在所有任务完成之前，应用程序保持不可用。最后一起调试的时候，往往会发现一些意想不到的问题。基于流程平台的通信。在测试过程中，沟通完全基于内部项目管理平台和即时通讯工具或电子邮件。比如开发人员在测试前需要在项目管理平台申请项目的4位版本。你拿到4位版本后，就可以提交给平台统一编译了。如果编译失败，问题解决后还得重新申请4-D版。如果成功，填写项目管理平台上的表格，回答一系列问题(比如，你做过单项测试吗？测量了哪些功能点？部署步骤是什么？)，启动测试工作流程，管理平台会自动发送邮件给相关测试人员，通知他们进行测试。测试人员收到测试工作流后，必须在平台上进行相关确认操作，通知开发人员已经收到版本。如果测试人员对部署和测试内容有疑问，他们也会通过即时通讯工具或电子邮件与开发人员进行确认。日常工作很难自动化。线上部署也需要通过内部平台完成。开发者拿到通过测试的4位版本后，要先登录内部平台，然后提交在线申请表，填写在线步骤。运维人员收到上线步骤后，会将其‘翻译’成平台可以识别的‘半自动上线步骤’，然后让平台执行。如果运维人员不了解在线步骤，要通过邮件或即时通讯与开发人员反复确认。部署信息分散在各处。如下图所示：
此外，该产品的一个重要特点是需要不断尝试调整程序算法策略，以获得最佳的流量效果，并且这种调整的频率较高(至少每周一次)。当策略需要调整时，开发人员修改代码，然后重新编译打包。随着产品代码的变化，测试人员仍然需要进行大量的回归测试，运维人员在部署时也需要对二进制包进行整体部署，这需要较长的周期。
从上面不难发现，在过程中，问题更倾向于后期解决(比如最后的集成调试)，以工具(平台、邮件、即时通讯)作为协作的基础，而角色之间的交流几乎完全依赖于前一个环节的产品(比如MRD、产品代码、上线步骤)。那么我们用什么对策来优化，达到消除浪费的目的呢？
四。对策1。无需人工干预的自动脚本测试3354因为已经日常集成，每天都有可测试的版本。开发者不再需要为测试做特别的准备，只需要从成功构建的列表中选择一个，交给测试人员即可。使用Hudson平台后，可以通过插件调用自动化脚本来完成测试版本的识别。统一配置信息源3354将所有配置项放入Subversion库中进行版本控制；根据应用环境的不同，分别存放在Dev、Test、Online三个目录下。
例行脚本——经过各角色的共同讨论和可行性分析，最终配置出上线部署的实施方案：开发人员将产品二进制包从配置项中分离出来，这样在只做策略调整时，测试人员只需要测试修改后的配置项即可。运维人员用一系列脚本代替内部运维平台的人工在线操作，再通过Hudson平台的插件，以‘点击按钮’的方式实现一键部署。2.尽早发现并解决问题‘需求细分、及时开发、及时验证’3354将需求拆分成端到端的可测试需求(即‘用户故事’)，一般可在3天内完成。在实现每个需求之前，开发人员和测试人员要充分沟通，就需求和验收条件达成共识。每次开发一个用户故事，它都会被测试，并被自动化测试所覆盖。主干开发，分支测试’3354原来的多个分支合并，统一在主干上开发。每周末抽出一根树枝进行测试，一旦发现问题，就在树干上进行修复。持续集成 3354为了保证每次提交的质量，为骨干开发建立持续集成环境，开发人员和自动化测试人员严格遵守持续集成签到舞的纪律。新的开发流程如下图所示。
分行发展战略改为单分行模式。
动词（verb的缩写）总结通过以上的改进措施，球队的配合方式发生了很大的变化，从‘地堡防守’变成了‘统战’。
原来所有角色都只专注于自己的工作。虽然大家都在同一个项目里，但是却划分了自己的‘领地’。产品经理要把MRD写清楚。如果开发者觉得不清楚，就回去改。开发人员只根据MRD的内容进行开发，很少考虑可测试性和可测试性。测试人员只根据MRD中的内容进行测试，通过内部工作流平台提交问题单。运维人员只根据开发者提交的在线操作单进行操作。似乎每个角色之间的沟通媒介只有自己的‘可交付物’。
现在，所有角色可以一起工作，以项目的最终交付为目标，积极讨论需求，优化实现。因为角色之间的这种紧密配合，大家对不同的角色都有了深刻的理解。开发人员耐心的为产品经理讲解技术实现和计划安排，测试人员和开发人员一起讨论验收条件，避免遗漏需求。开发者让运维人员了解架构设计，认真听取运维人员的建议，进行技术改造，让部署工作更快更有效。
通过这些活动，大家认识到原来的内部管理平台只是一个公文流转的支撑平台。为了提高工作效率，这个“办公自动化工具”应该进一步升级为“全自动化工具”，这样每个人都会更加关注端到端的价值，而不是角色之间的分界点。
不及物动词结论百度刚刚开始敏捷之旅，还没人谈‘devo PS’运动。虽然没有强有力的工具支持，但是基于‘提高效率’这种简单思路的流程改进也带来了‘devo PS’效应。可见DevOps听起来很玄乎，其实并不难。只要你遵循精益思想，专注于价值的快速交付，不断发现和消除浪费，你一定会收获很多。
