随着2015年的结束，Gartner预测到2016年DevOps将变得主流，预计将有大约20000家世界顶级组织采纳这一理念。DevOps的理念承诺了许多好处，但在成功应用DevOps之前，需要认识到一些重要的障碍需要被克服。
实际上，DevOps已经以某种形式存在了一段时间，但目前对于软件开发和运维团队如何更好地合作的关注，很大程度上是由一系列新工具推动的。像Docker和Vagrant这样的工具在很大程度上释放了DevOps的潜力，尽管它们本身并不足以实现这一切（稍后会详细讨论）。另一个推动因素是开发和运维不能再作为两个完全独立甚至有时相互对立的派系存在：持续开发、敏捷和更快的市场上市时间的潮流要求更加协作的方法。
这带来到了挑战的核心：只有当每个人都对正在开发的内容和即将进入生产环境的内容有共同的理解时，应用DevOps方法论才会有效。除了文化障碍之外，不要忘记他们通常使用完全不同的软件工具来完成他们的工作。
持续交付（CD）将有助于实现这种更透明的方式。根据Evans Data Research去年的调查，大约三分之二的英国和美国组织已经采用了CD，CD是关于创建一种协作和及时的方法，将软件项目从构思阶段一直到部署阶段。在实践中，这意味着能够在任何给定时间将软件发布到生产环境。CD的核心是开发管道，在其中可以包括早期反馈、增量部署和自动化构建测试，所有这些都加速了发布周期。
像DevOps一样，CD在理论上有很多好处，但仍然回到了起点：只有拥有正确的文化和正确的技术工具，两者才能成功。其他组织可能更适合评论如何实现文化平衡，所以让在这里专注于工具。以下是根据与成功实施DevOps的客户合作以及该领域领先专家的建议，整理出的一些“最佳实践”步骤。
不要局限于代码思维——如今，大多数基于软件的产品涉及许多不同类型的资产，如文档、视觉内容、二进制文件和配置脚本。这些需要在整个发布周期中一起管理，否则就有向客户交付不完整或有缺陷的应用程序的真正风险。
尽可能自动化并持续测试——这里的目的是能够快速、安全地进行更改、调整或更新，同时尽量减少错误潜入的风险。解决方案在于拥有一个统一的持续管道，尽可能自动化整个过程，使失败能够在早期反馈给开发团队，以便他们可以进行必要的更正。在开发阶段发现问题比资产到达QA测试时更有效。当然，并非流程中的每一个元素都可以自动化，这是一个找出哪些可以自动化，哪些仍然需要一些手动干预的问题。
寻找单一事实来源——任何成功的DevOps项目的核心应该是一个单一的、统一的存储库，它连接着每一个人和资产，但更重要的是，不要创建过于僵化的工作实践。员工应该能够继续使用他们自己的方法和工具，因此版本控制存储库需要能够无缝地与各种第三方软件集成，并且是技术不可知的。鉴于大多数软件项目正变得越来越大和越来越复杂，版本控制存储库还需要能够扩展。