开发人员社区中流传着大量的DevOps神话。考虑到近年来DevOps概念的流行，这并不奇怪。

DevOps是鼓励采用敏捷思维来提高软件交付过程的速度和质量的实践。在DevOps中，开发团队与运维团队的相互合作，贯穿整个软件生命周期，二者对自己的具体任务负责但并不真正在一起工作。

如果实施得当，DevOps方法可以为组织带来显著的积极影响。它可以降低成本，提高效率，并使开发团队的工作更加精简。为了掌握这个过程的优势，有必要认识到DevOps是什么、不是什么。在本文中，就将讨论一些流传甚广的关于DevOps的一些误解。

×DevOps就是CI和CD

关于DevOps最大的误解之一是它与CI/CD是一回事。事实上，持续集成和交付只是DevOps生命周期的一环，是Devps的关键组件。

DevOps注重团队的文化和责任感，它强调团队中的每个人都需要参与彼此的任务，这样可以提高团队中的协作和沟通能力。

另一方面，CI/CD通过强调自动化的软件和工具实现了这种沟通的文化，所以可以将CI/CD看作达到DevOps的手段。

×DevOps意味着NoOps

NoOps的概念描述了云基础设施足够自动化，以至于不需要手动管理。

NoOps被认为是DevOps的下一个发展模式。与DevOps一样，它的目标是改进软件交付，但允许开发人员专注于应用程序开发，而不必在基础设施和维护上花费过多精力。

通过使用机器学习和人工智能，可以自动化设置、部署和监视过程，从而更接近NoOps。

×自动化消除了所有瓶颈

自动化是DevOps提供的最大好处之一，但它不是可以解决所有问题的银弹。

持续交付过程使团队能够快速推出新功能，并且更快地得到所需要的反馈。当然，这意味着必须确保产品的质量。此外，在扩展时必须考虑到运行情况和性能，还需要确保顺利的生产部署。

自动化CI/CD管道有助于消除代码提交和部署之间的瓶颈。但这只是软件交付过程的一个阶段。除非开发人员和测试人员结成伙伴关系，否则无法解决所有问题，且很可能只会将问题转移到其他流程。

×一刀切式的持续交付管道

拥有一个适用于所有团队和公司的流程是不可能的，这与普遍的想法相反。每个组织都有不同的需求和要求，即使是同一组织中的不同项目也需要不同的持续交付管道。

您可以有只需要两到三个环境的项目。例如，频繁部署的开发、测试和生产环境。在软件交付周期中有多个阶段的项目可能就需要更多的环境。

这就是为什么持续交付管道应该符合公司已经在使用的发布过程。

×DevOps即工具

关于DevOps的讨论主要集中在公司使用的工具上。然后就变成了关于什么是最好的工具的哲学争论。相反，应该交流关于更大的前景，如DevOps给公司带来的商业价值。

DevOps意味着关注文化、心态以及个人如何协同工作。只有在此之后，才应该为流程选择正确的工具。团队经常在工具的大生态系统中寻找最完美的解决方案。构建DevOps管道的时间很长，一旦完成就应该重新进行。

Atlassian的一项研究表明，成功实施DevOps的两个主要因素是合适的工具和合适的人员。

×软件发布与Amazon/Facebook/Google相同

由于DevOps的优点和灵活性，许多世界领先的公司都采用了它。看着这些公司的成功故事，我们当然会敬佩他们的成就。但我们效仿的时候，却忽视了他们的背景和成功的步骤。

有一件事是肯定的——这些组织选择并构建了当时最适合他们的工具和流程。这并不一定意味着我们一定要效仿这些组织。此外，他们所做的不会奇迹般地对我们的业务也起作用。

我们应该向他们学习，寻找创新和发展的新途径。探索并找到定义问题空间的正确流程和工具。什么会给我们的事业带来成功？这就是DevOps的全部内容。

×随时发布

频繁发布的想法让公司担心他们的软件发布不够连续。“船常”已成为行业标准。但是，这并没有指定时间。可能是每两到三个星期，也可能是一天几次。

最重要的是获得了团队的信心，使您能够在需要的时候发布新软件。CD是一种从主分支发布代码并对其充满信心的能力。DevOps的理念是你的代码应该在任何时候都可以发布。

所以请记住，持续交付并不意味着您应该尽可能频繁地发布，而是给予想要的频繁发布的能力，而多长时间发布一次应该由公司决定。

希望这篇文章能帮助你解开一些广为流传的DevOps误解，不要让这种误解阻碍你团队的进步。实施DevOps可以帮助你的公司提高生产力，创造更好的产品，所以不要因为这些DevOps误区而错失良机。

作者：陈琦，资深敏捷测试顾问，作为国内知名项目管理软件——禅道的团队成员，主要负责开源自动化测试管理框架——ZTF的开发工作。拥有十多年的敏捷过程实践经验，现致力于测试自动化和DevOps相关领域的实践和研究。