将软件开发和IT运维团队整合到单一的DevOps组织可以带来更强大的软件开发项目交付能力，但两类团队的文化差异、以及缺乏有效的工具都会阻碍DevOps的成功。

[[126874]]

越来越多的公司开始向DevOps模式转型，希望能更迅速地将越来越多的软件更新和修补程序交付到用户手上，而且能实现比传统模式更短的软件更新周期。

在持续的竞争压力下，能够更快发布软件产品的公司显然会拥有更强的竞争优势。

Gartner研究总监 Colin Fletcher 在2014 Gartner IT基础架构和运营管理峰会上表示，“它(DevOps)将决定你进军新市场或者推出新产品的速度”。Fletcher认为，新兴市场的竞争压力、适应新的计算平台，为产品增加新功能、提升能力，这些都是转向DevOps的理由。

传统的软件开发是一个人工过程，每一代产品从源代码到测试到发布的过程都会跨越组织内部多个相对分离的领域。虽然让开发人员、测试人员和其它岗位人员融合无间，消除相互之间的合作壁垒是DevOps的终极目标，但每个公司都会用不同的办法将DevOps付诸实现。

Gartner公司资深VM分析师Ronni Colville表示，开发人员和运营人员对于软件发布管理的看法完全不同。在软件开发人员眼里，软件是代码、功能和性能。然而，运营人员眼里的软件是致力于将代码数据传送到目的地的一个流程或者行为。如果能整合两方的看法，就能大幅精简流程，减少理解上的误差。

1.应对DevOps带来的文化冲击

平稳的文化过渡是让DevOps获得长期成功应用和增强发布软件产品的综合能力的关键。第一步是，明确DevOps的定义，调动开发和运营部门之间的协作，鼓励运营人员采纳软件开发方法，并利用云计算基础设施来完成真实的测试和代码部署。

在软件开发、测试、质量保证(QA)、集成、预生产和生产部署等方面的任何旧小团队必须打散，因为每个小团队都可能拖延开发周期并且带来不可预料的问题。

以上策略能更好地整合开发和运营人员，通过整合团队成员来产生效益。例如，在讨论运营解决方案或扰乱事后评估报告时应该邀请开发人员加入。相反地，应该邀请运营人员列席开发人员规划会议。让交叉组合的工作模式成为制度，可以让团队之间合作融洽，消除沟通不畅导致的延误或疏忽，使DevOps的推进更加有效。

这种文化上的改革并不容易。它需要公司提供统一的考核标准，以相同的形式衡量开发人员和运维人员的业绩。培养一种团队精神，让大家一起向一个共同的目标努力，而不再只是为了从前各自的狭隘的小团体目标。在这里有时可以运用岗位轮换或者知识共享的方法。Colville鼓励大家勇于尝试——尝试用创造性的新方法处理问题，谨慎应对风险，从失败中积累经验。

在Bob Jones 大学的案例里，开发和运营团队之间的文化差异成为巨大的挑战。

“从前我们的客户都没有好脸色”，Bob Jones大学IT运营总监Terry Worley表示，“我不得不拿着鞭子驱赶运营和开发人员，迫使他们在工作上认真地合作。我深有体会，文化差异是拦路虎，我要么坐着等死，要么就该去杀了它!”

Worley已经证明了文化变革的好处，他指出，在采用了优化后的DevOps模式完成两个项目之后，开发人员们就再也不想回到从前的传统软件开发模式了。

2.DevOps需要齐全的工具箱

想要超越文化的影响，组织还必须依靠各种 DevOps 工具。例如，开发人员编写代码需要工具、QA测试人员需要用工具完成新版软件的部署，环境准备、将新代码在测试系统和生产系统之间迁移也必须用到云资源调度工具。Fletcher表示，工具本身都不是问题，重要的是能够让各种工具互相配合，在软件的生命周期内提供支持。

当前在应用程序发布自动化工具市场已经存在众多的供应商。运营工具方面的供应商有BMC Software, CA Technologies Inc. 和 XebiaLabs Inc.等公司。软件开发工具方面的供应商包括IBM，Electric Cloud Inc.和Serena Software Inc。

关于开发人员工作流程、架构设计和软件发布工具方面的专业供应商也在不断涌现，这些供应商包括Atlassian, CollabNet Inc., Rally Software, ThoughtWorks Inc. ，OpenMake Software Inc.等公司。在评估这些新供应商时，应明智地预计到这些公司随时可能会被并购，其产品可用性和未来发展也会因此受影响——请记得在选择新的软件发布自动化产品时多留个心眼。