DevOps 已成为使开发人员能够更快地移动和交付更多软件的代名词，但无意中将软件质量和测试推向了一个角落。在非常缓慢的测试和远离过于技术化的解决方案之间来回摆动的钟摆在 DevOps 中摇摆不定，完全忽略了测试人员通过强迫客户测试新代码和创建依赖监控系统来查找问题的团队可以带来的价值这可能在客户注意到之前就已经被发现了。
DevOps 已经从基于对开发可能是什么的猜测转变为开发人员角色的真实部分。让我们看看我们如何才能将这种趋势转回一个更负责任的地方，仍然使用 DevOps 来更快地发布软件，但要达到客户满意的质量水平。
持续集成与交付
持续集成 (CI) 和交付 (CD) 是 DevOps 中内置的两个最基本的概念。他们帮助我们讨论了每次将新代码行添加到存储库时都会构建新产品的工具，然后在构建完成后立即将其部署到生产环境中。一些更专注于技术的公司，如 Github，已经尽可能地推动了这个想法，并且每天都在多次将新软件部署到生产环境中。
这种快节奏开发和发布风格的副作用是，真人在交付前试用软件的任何时间都被挤出了。一旦有可以运行的软件，它就会投入生产。付费客户是新的测试人员，监控和报告系统是新的错误报告。
如果我们稍微回拨一下，我们会得到一个策略，开发人员在他们自己的环境中进行 CI，每次他们提交到本地源代码存储库时都会获得一个新的构建。在签入主仓库后，代码会持续部署到暂存环境中。
我在较小的团队中持续部署到无头 API 服务器方面取得了很多成功。我工作的一个团队有两个人在 API 平台上工作，我们的其他产品都是在这个平台上构建的。每次他们提交代码时，一个新的构建都会发送到该服务器。通常在那之前，我们会坐在一起讨论变化和他们的担忧。我可能会开始做一些自动检查，并写下一些测试想法。
我们仍在使用 DevOps 概念来快速构建 API，但我们这样做的方式不会强迫客户处理我们的问题。
监控只是解决方案的一部分
一些大公司正在使用在后台运行的复杂 API 和 Web 监控系统 ，从 API 中吸取大量日志数据以寻找一些重要的关键字，如 Exception 和 Error。每次找到这些词时，都会发送电子邮件和短信，让开发人员知道出了点问题。
也许您有一个完全组件化的产品，您可以在其中翻转位以快速打开和关闭功能，以减少故障风险。一些公司拥有作为组件构建的零碎产品，少数公司拥有大量产品。大多数很少或没有。对于较小的公司，这意味着在开发架构上花费与构建产品相同的时间。这不是大多数创始人和投资者希望看到的比率。
监控和回滚系统对于 API 产品非常有用，但对于急需产品销售的年轻公司通常不可行。
消费者的地雷和收入的漏洞
在没有生产前测试的情况下使用监控对您和您的消费者来说是危险的。想象一下，您正在发布一个新版本的 API，它将帮助客户使用他们手机上的地理位置信息来查找附近的商店。 API 底层的代码有一些使用伪造数据的自动检查，以查看商店是否正确返回，但只有少数，而且非常简单。
您的第一批使用此功能的客户之一住在夏威夷的岛屿天堂，碰巧那里有许多城市名称中都有特殊字符。部署几个小时后，服务器日志文件因 Kāne'ohe 和 'Ewa Gentry 的人试图找到最近的 Dunkin Donuts 的错误而爆炸。
电子邮件开始在开发办公室中飞来飞去，几分钟后该功能被关闭，但损害已经造成。当您的支持人员与开发人员取得联系并且该开发人员进行调查并采取行动时，您的客户已经放弃了。这些用户中约有一半卸载了该应用程序，转而使用 Google 进行搜索。
使用您的客户来测试新代码会产生真正的后果。将熟练的测试人员放在该 API 的前面可能会提出这样的问题：“对于名称非常长或特殊字符的城市，或者可能并非所有地图系统中都包含的非常小的城市，会发生什么情况？”。 测试新的 API 更改 会使您的产品以 DevOps 永远不会出现的方式暴露于黑天鹅问题。
像这样的案例确实发生过，并且是使用 DevOps 概念在内部而不是生产中交付的好例子，可以节省一些客户和公司的资金。
DevOps 提出了一套强大的想法，可以帮助我们比以往更快地向客户交付代码。它们也可能是一种危险的方式，可以比我们希望的更快地交付错误的代码和有缺陷的产品。如果我们通过将 DevOps 主题与熟练的测试人员配对来放慢一点速度，这些想法和工具可以帮助我们更快地交付软件和 API 更新，而不会让我们的客户面临新的风险。
您有将 DevOps 与测试集成的经验吗？我们很想听听您的故事。
本文最初出现在 Justin Rohrman 的 SmartBear 博客 上。
