2015年，开发部和运营部仍然会有千丝万缕的联系，因为这两个部门会共用许多有利于二者关系顺畅的工具及平台。但是，所面临的挑战是，我们仅仅得到未来五年意义深远的变革承诺而已。跟其他许多流行趋势一样，当DevOps成为商用环境中一个笼统的称谓时，那么它受人关注的程度就会淡化。Jevgeni Kabanov对此表示无奈与遗憾。“我对DevOps这个主题有些不解，因为，我不确定其定义是否完善。它起到一个旗帜的作用，我真的想要让操作系统朝着它的方向发展。”然而，Kabanov却指出，许多工具集和解决方案都被标上DevOps标签，但是我们却不理解实际运行中究竟是什么样。

DevOps仍不具备精确性

ZeroTurnaround公司的创始人兼首席执行官是如何定义这个概念呢?Kabanov跟我们是这样解释的：“我认为DevOps包含两部分。一部分是要打破开发与运营之间的壁垒。这个两个部门都会担忧他们该如何为消费者创造价值，无论他们是内部消费者还是外部消费者。另外一部分则更像是来自于开发人员所带来的一种潮流，因为他们在运行过程中使用更多的开发技术。如今所编辑的运行程序中越来越多的添加了Chef、脚本基础架构、云以及部署等功能。这些功能都有助于让持续交付的程序可以正常运行并返回到构建的路径上。这种模式适用于整个生命周期中。”

实现持续交付

Karsten Bugner是Pernexus Systems的技术总监，他对公司最近开始使用的XRebel和JRebel开发工具给予了高度的肯定。当证实传统的开发方式会降低开发效率时，公司决定进行转变。“从某一刻开始，自动分类和注释就不再起任何作用了，在任何一个阶段和类别中都过于沉重而不能顺利地在拦截器中运行。此时，我们就应该寻找解决方案来重新分类、装配。”

在无需总是重新启动服务器的情况下，Bugner迅速地学会了如何运用这种功能并反复进行部署。与标准分析工具相比，他对现在这种带有轻量级工具更满意一些。“使用像JProbe这样的标准工具，你可以找到所有文件。我们已经拥有了一种知名的分析工具，想要找到所需信息需要花费一到两个小时的时间。有了 Xrebel，你不会再为时间问题而苦恼，而是会更加迅速得地完成指定任务。”

首先要注重理念，其次才是工具

Simon Maple在ZeroTurnaround公司的推广部工作，他对SonarSource赞不绝口，因为它可以确保代码质量。但是，他所说的质量是从两个方面进行判断的，其一是要选择合适的工具，其二就是将其运用到实际工作中。不幸的是，许多开发团队在执行方面通常达不到预期的效果。

“通常，第一次开发人员使用一种质量工具，然后他们便会将其放下，形成一种摆设而已。持续使用合适的代码质量工具才能保证软件的开发质量。我们应该将这些工具反复整合到开发流程中。它们应该成为构建流程的一部分，从而当这些工具发现问题时，构建才会彻底失败。”

从实用性角度来看，我们可以从两个方面解读DevOps。一是Ops，它可以使开发过程更加顺畅。二是Dev，重新对如何实现运行系统的无缝部署和管理进行思考。这就意味着，Dev和Ops不能分开进行。

Maple认为，二者的分离仍会产生很大的问题。“开发人员能否在同一生产环境中进行有效测试是非常重要的一个环节。我仍然看到有些客户正使用着Jetty开发环境，然后变化转向WebSphere生产环境。使用这种方法，一些严重的质量问题便会影响到程序编码。使用一些简单的方法就会解决这些问题。这种简单的方法就是改变人员开发高质量软件的心态，而不是仅仅改变开发工具。”

为了实现更好的DevOps做出最佳选择

定义DevOps：对于该方法来说，或许不仅仅只有一种定义。但是，至少在任何一个组织中， DevOps所要实现的目标和成果应该是可以达到统一的。达成共识，然后，从那里开始工作。

重新构思工具：如果现有工具阻碍了持续交付的进度，那么就应该做出一个新的选择，在不降低质量的情况下实现更高的生产力。我们应该决定多大的信息量才足以交付工作软件。

关注流程和实践：工具改变不了人们的文化。仔细观察目前的DevOps流程，找到需要改进之处。为了形成更好的实践，我们应该采用一些培训和激励政策，同时协作地使用一些恰当的工作来支持这些改变。