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

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

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的应用发布解决方案，——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解决方案平台做到了这一点。