自动化和适当地应用规则可以实现更高质量的测试、更短的产品发布周期并且能够降低业务风险。
作者
ThomasA.Limoncelli
译者
彼得（王丰力）
责编
屠敏
我的一位朋友最近对我说：“因为我们使用SQL数据库，所有我们不能应用DevOps方法”。我很奇怪人们会有这种观点，因为它在许多方面都是错误的。
他说，“你不了解我们的情况！DevOps意味着我们将更频繁地更新我们的软件。但是，我们也只是勉强维持，我们每年只能把我们的部署更新几次而已！”
我向他询问了他们目前的部署流程。
他解释说，“我们每隔几个月就会获得一个新的软件版本，但是将它们部署到生产环境需要大量的工作。因为我们使用SQL，所以我们的部署就是：首先，我们停止所有用户的访问。然后，我们停止应用程序的运行。接下来，DBA（数据库管理员）就开始修改数据库模式。当他们的工作完成以后，我们就开始安装和启用新版本的软件。这个过程需要花费很多的时间，所以，我们经常在周末进行升级。对于这一点，我也很讨厌。如果升级失败，我们就必须恢复备份磁带，并从头开始恢复所有内容，最后，重新启动。“。
他总结道：“仅仅安排这样的升级活动，我们就需要花费数周的时间进行协调。我们也经常协调失败。这就是为什么我们不得不在周末进行升级。每隔几个月就有一次这样的经历，真的让人感到很痛苦，这也是我们所有人最大的压力来源。如果我们每周发布一次，我们中的大多数人都会辞职。我们没有周末呀！我听说有些公司一天发布软件多次，如果我们这样做了，我们的应用程序就会一直处在停机、升级的状态！”
好多事情需要解决。我先澄清一些误解，然后，我们再讨论一些能使这些部署变得更加简单的技术。
首先，DevOps不是一种新技术，而是一种方法论。DevOps最简洁的定义是它将敏捷/精益生产(Agile/Lean)的方法贯穿于从源代码到生产环境的整个软件生命周期。这样做的目的是为了“更快地交付价值”，也就意味着缩短软件从构思到产品上线的周期。更频繁的发布意味着新实现的功能在投入生产环境前需要等待的时间更短。
DevOps不强制要求或禁止任何特定的数据库技术或任何其他的技术。因此，你没有任何理由说因为某一种特定的技术，使你能或者不能应用“DevOps”。同样，你也不能说在某个项目中因为你使用特定的语言，所以你不能应用敏捷开发。SQL可能是一个不应用“DevOps”的常见的理由，但是，这个理由经不起推敲。
我很理解在某些人的思维中，DevOps之所以能够使用，是因为对应的应用没有SQL数据库。在年代和年初，发明和普及DevOps的公司通常是大型网站，很凑巧的是，它们都使用NoSQL（键/值存储）数据库。然而，将这没有因果关系的两者联系起来是没有道理的。这些公司也在向员工提供精美的免费午餐，但是，我们都知道这不是DevOps的先决条件。
其次，我不认为应该说有人可以“做DevOps”。你可以使用DevOps相关的任何技术和方法。人们经常使用说“做DevOps”，这就让我很难解释。
我和我的朋友进一步讨论了他的情况，很快他就意识到DevOps对他来讲并非不可能；这只是一个艰难的转变过程。然而，一旦转变完成，他就可以很容易地应对他的工作。
我的朋友还有一个疑问。他说，“你看，这些部署都有风险。我们每做一次，我都会冒着公司数据丢失的风险。说实话，做出这些改变是我份内的事，但是，我真不想这样做。每隔几个月经历一次就够让人紧张的了，如果还要更频繁地做这些事，太难了。“
正如我在之前的专栏（”小批量原则”，发布于acmqueue的14卷第2期：