科技行者

行者学院 转型私董会 科技行者专题报道 网红大战科技行者

知识库

知识库 安全导航

至顶网软件频道应用软件CA:DevOps的终极目标——持续的交付

CA:DevOps的终极目标——持续的交付

  • 扫一扫
    分享文章到微信

  • 扫一扫
    关注官方公众号
    至顶头条

当一个名词被不断提及,就是火了吗?但是,受关注的程度与被了解并很好的执行并不一定成正比。DevOps,就是一个例子。对于DevOps的定义,有人说是一组流程、有人说是一个概念、有人说是应用开发和系统运维团队执行任务的混合体,还有说是一个软件方法……

作者:邓晓蕾 来源:ZDNet软件频道【原创】 2015年6月25日

关键字: CA DevOps 持续交付

  • 评论
  • 分享微博
  • 分享邮件

ZDNet至顶网软件频道6月24日  原创文章 (文/邓晓蕾): 当一个名词被不断提及,就是火了吗?但是,受关注的程度与被了解并很好的执行并不一定成正比。DevOps,就是一个例子。对于DevOps的定义,有人说是一组流程、有人说是一个概念、有人说是应用开发和系统运维团队执行任务的混合体、有人说是一个新兴的软件集成以及IT业务的沟通协作方式、还有说是一个软件方法……这些理解,你认为都对吗?

CA:DevOps的终极目标——持续的交付

DevOps的演进

先来看看DevOps是怎么发展起来的?一开始DevOps由两个运动组成,第一个,被称之为敏捷系统管理的运动,触发点是2008年举办的Velocity Conference会议,主要讨论关于Web的运维,以提高整个web运维的效率。之后,2009年的时候由Gordon Banner正式地推展敏捷系统管理的运动。第二个,对DevOps的历史有影响的运动叫企业系统管理的运动,在2000年中旬的时候,由John Willis和Mark Hinkle这两个人开始。这两个运动的结合也就是DevOps的运动。

开发人员VS运维人员

平时,在工作当中,我们常常遇到相关不同角色的一些同事,甚至同处于一个项目中,像开发人员,环境准备人员,测试人员,运维人员,以及负责应用支援的人员、业务主管等。但经常各自划分了"领地",开发的同事常会告诉我们说,我用了70%时间来等待;环境准备人员常常谈论没有多余的环境了;测试人员常常告诉我们说,测试环境不够真实,运维的同事会说应用发布就是噩梦,应用支援的同事更惨,常会问怎么找问题?但是,你发现没,里面缺少了一个很重要的角色,就是业务主管,“业务主管常常会对IT部门说:“你们IT在做什么,我们正在错过外面所带来的业务的机会,我需要新的应用,我需要新的功能……”。可见,各角色仅关注于自己本身的工作,而非各角色之间的分界点。

IT正处在变革当中,现在大家在谈论最多的就是应用经济,因为,应用经济所带来的机会是巨大的。但是,很多时候我们发现没有很好的抓住这些机会,其实这是由于IT创新能力的低下。面对业务所带来的需求,我们仍选择的是二十年前开发应用的方式来进行应用运维,这说明,IT需要补足这个差距。

到底是什么导致停滞不前呢?根据Forrester的调查数据显示,低于40%的决策者认为IT能按时,按预约提供新服务,75%的决策者认为有必要提高整体IT的效率,这里面包含 IT的效率、创新的能力、简化的流程、工作的效率。

DevOps的精髓,整体观念

那么,问题怎么解决呢?IT部门的骨干是有两个最主要的工作部门组成的,一个是研发(Development)另外一个是运维部门(Operations),他们都有自己的思维方式来做事,研发同事常会需要快速地创新,写简易的代码,简单使用,Agile交付等更多功能上。而负责运维的同事有另外一套思维模式,需要系统稳定地运行,最好是十年都不做任何的改变,完善的安全机制,更简易的管理步骤等等。

而如何把这双方的差异点整合起来,就是DevOps的精髓。DevOps(开发运维)是Development与operation这两个词所组成的。CA公司认为,DevOps所要达到的目的是确保稳定的创新,使用敏捷开发来交付应用,敏捷运维来运维应用,这是DevOps整体的观念。

整合开发和运维人员

目前,在高速竞争的市场,如何快速地把应用推出,如何快速地交付新的服务,成为IT不可避免的问题。那么,一套增强开发及运维之间的集成,协作及沟通的方法是很有必要的。而DevOps恰巧就能协助各个企业解决这个问题,快速地把应用交付出来。

DevOps首先,可以更快地交付业务的价值,在服务交付的过程中打破孤岛,即打破开发与运维之间沟通的成本;第二,整合开发和运维的能力成为一个协作的团队,他们不再是开发,不再是运维,而是IT的团队。第三,DevOps最主要专注的是端到端服务交付流程的变革。

当实现整个DevOps的交付过程当中,必须要确保流程的变革、新式工具的推广、或者新工作流程推广的时候是不影响安全性,应用的兼容性,以及应用的性能,这是DevOps所需要带来的一个价值。

DevOps的终极目标,持续交付

那么 DevOps的终极目标是什么?CA称之为持续交付。DevOps打破信息的孤岛,让开发与运维之间更好的协作。协作目的是确保应用能快速地由开发流转到测试,再到运维。当运维遇到问题的时候,能建制一个完整的闭环回到开发环节。

我们知道,一个应用的开始都是由开发人员开始把我们的应用开发完成了,当然我们前端还有我们的相关业务部门,业务部门把这个需求提给开发,开发的同事分析完需求之后进行他们的开发,开发完之后相关的代码我们会放到我们的代码库上,这是大家现在常做的做法。

在一个持续交付的观念里面,开始由相关业务部门根据需求提供给开发人员,开发人员分析完需求并并行开发,开发完成后,相关的代码会放到代码库中。这时候应该有一个持续集成,也就是构建自动化(Continuous integration)平台,平台提供开源的工具、持续集成的工具、build的工具来进行建制持续的集成。

CA DevOps解决方案

 CA:DevOps的终极目标——持续的交付

持续集成的结果就是工件,工件可以存到代码库上,之后让持续集成工具开始来呼叫CA的应用发布解决方案,——CA DevOps解决方案,将会由工件库把最新的工件取下来,比如, ear file, war file, jar, exe 等等,这时,会自动结合发布清单把相关的应用透过已经定制好的发布流程,发布到SIT环境上去。

那么问题来了,在正常的状况下,手工进行SIT的测试,为了实现持续交付的目的,自动化的测试变成必不可缺的一个环节。在这个环节上CA DevOps解决方案能呼叫下一个解决方案(CA Service Virtualization)。CA服务虚拟化包含了两个部分,第一部分是测试的发起端,它包含录制网页的一些测试脚本,也包含透过传输协议直接发起的测试,甚至包含移动终端的一些应用的测试。

另外一部分,是能把测试过程当中应用所依赖的第三方的内外部的资源,透过服务虚拟化解决方案资源透过一定的手段虚拟出来,这样就能达到真正的自动化测试。当启动服务虚拟化之后,能自动针对SIT环境上面所部署的应用进行自动化完整的测试。

在测试过程当中一切顺利的话,下一步会回馈到自动化的解决方案平台,将会针对下一个环境UAT的参数、配置,跟当初所测试的工件做一个集合,然后发布到UAT环境上去,同样,使用CA服务虚拟化解决方案,直接进行自动化完整测试。若测试过程当中发现某一个错误发生了,就能自动地回滚。 CA DevOps解决方案平台能自动把应用回滚成旧的版本,而且是在各个环境当中都能自动地都回滚成旧版本。

接下来CA DevOps解决方案平台用同样的工件结合同样环境发布清单,把应用完整地发布到生产环境上面去。而在生产环境上会面临一个挑战,就是没有办法进行任何流程或是交易测试。原因很简单,因为在生产环境上做任何测试都会影响到生产的数据。所以,往往发布之后是没办法进行完整的测试,只能等到使用者上线使用的时候才可能发现问题。但是在高竞争的环境底下,当发现问题已经太迟了。透过CA服务虚拟化解决方案,在测试环境上就开始进行相对验证了,在这个场景下除了应用是真实的,发起端、接收端都是虚拟的。这样进行完整应用的交易测试以及确认应用发布完成,一切正常。

CA DevOps解决方案平台还有一个特性,就是在发布过程当中把所有的数据记录下来,比如,做过的动作,进行的工作,都完整地记录下来,供后续的发布报告分析。

DevOps的终极目标,也就是持续的交付。出发点是为确保提高整体IT的运维,研发,以及交付能力效率。CA DevOps解决方案平台做到了这一点。

 

    • 评论
    • 分享微博
    • 分享邮件
    邮件订阅

    如果您非常迫切的想了解IT领域最新产品与技术信息,那么订阅至顶网技术邮件将是您的最佳途径之一。

    重磅专题
    往期文章
    最新文章