转载

精益机器：将敏捷思维引入数据库开发

多年来，敏捷实践携短迭代、快发布、更快推出软件的承诺一直吸引着应用程序开发人员。现在，同样的做法已经进入数据库领域，但是，数据库开发团队该如何采用那些做法，他们应该从哪里开始？在本系列文章的第1部分（共2部分）中，Matt Hilbert阐述了如何从版本控制入手将敏捷思维引入数据库开发。

敏捷号称无所不在。开发人员喜欢它，因为它简化了流程，改进了软件质量，实现了重复工作的自动化，并支持持续交付，使他们可以将精力集中在他们擅长的事情上：编码。

许多公司喜欢它，因为就像Puppet Labs发布的《 2014年DevOps现状报告》所显示的那样，那些使用类似敏捷方法的企业，其利润、市场份额和生产率目标都超出了两倍。

Gartner甚至将将敏捷软件开发列入了 2015年十大高科技趋势，将其视为数字经济的驱动力之一。

但这对数据库开发人员和管理人员意味着什么？他们无法承受匆忙随意地数据库变更。默认情况下，他们需要事先做大量设计。

由于整个的数据库开发过程都比较谨慎、缺少敏捷性，所以将敏捷实践（如持续交付和自动化费力的任务）应用于数据库开发过程是一个真正的技术挑战。敏捷意味着向现有的做法中引入新技术、陌生的流程和没有使用经验的工具，同时也意味着，在现有的部署方式已经够用的情况下，冒着风险更快、更频繁地部署。

是那样吗？将敏捷思维应用于数据库开发，开发过程会更简洁、更迅速，浪费更少，质量由开发过程保证，可以避免后续许多部署问题。

游戏规则已经变了

事实是，敏捷和持续交付已经像野火一样席卷了应用程序开发领域，数据库开发领域也出现了许多敏捷活动。这是一种很自然的扩展，因为业务快速变化，功能发布速度需要加快，而数据库不能成为瓶颈。

在数据库开发、测试和部署方面，有一些工具和流程可供采用，而且可以同应用程序开发所使用的工具和流程一起使用。将数据库视为另外一部分源代码，并采用敏捷实践，数据库生命周期管理（DLM）会变得更简单。

使用方法正确的话，DLM可以减轻数据库管理员（DBA）的负担，简化和加速测试过程，将偶尔的、让人满怀担忧的大规模部署转化成简单安全的频繁部署。

同时，它将DBA的角色由看门人转变成推动者，前者有时候会被认为阻碍了部署，而后者却让部署更简洁。

那是个很大的变化，或许有些出人意料，开始实施敏捷还是比较简单的。

统一所有人的思想

第一步是考虑协作，而不是竞争。在关于DevOps的著名小说 The Phoenix Project 中，对于应用程序开发人员和DBA之间的分化，主角Bill Palmer有一段精彩的评论：

你不能仅仅把猪从墙头扔给我们，然后就在停车场互相击掌庆祝你们如何在最后期限到来前完成了任务。Wes告诉我们，猪可能摔断了腿，而为了让它活下来，我的人就需要没日没夜没周末地工作。

这种分化是不必要的——在数据库开发中采用敏捷思维，这种分化将不复存在。目标是实现更小更频繁的发布，开发和运营团队互相交流，并且总是在较大的问题上进行协作：提供高质量的软件。例如，运营团队会事先强调，建议的变更会对数据库产生什么影响以及为开发人员带来什么后果。

Moneysupermarket.com数据架构师David Poole赞同这种观点。在文章《 DBA和开发人员比较：无谓的冲突导致了悲伤的故事》，他在结论部分写道：“经验告诉我，当开发人员和DBA一起很好地合作时，他们不只是增加了彼此的效率；他们的效率翻倍了。”

选择恰当的工具

第二步是要记住，敏捷意味着改进工作方式。这不是说引入工具强制执行变革，将严苛、陌生的规则、工具和流程强加给每个人。相反，它要求以更好的方式使用现有的工具，就像Alex Kuznetsov在《六年敏捷数据库开发的教训与经验》中所写的那样：

敏捷是一种群众运动，不能只是简单地将特定的工具、技术或方法强加给不情愿的团队。

例如，你可以使用应用程序开发人员所使用的版本控制、持续集成和发布管理工具，实现数据库变更的版本控制、测试和部署。

这样，就不需要引入没有使用经验的工具，那虽然可以完成工作，但会增加对人们的制约，而通过充分发挥数据库工具的作用，并结合现有的应用程序开发工具，你同样丰富了工作方式。

通常，这还会带来额外的好处，应用程序和数据库开发团队齐心协力向着共同的目标努力，真正实现开发过程的整合。

小处着手

持续交付、持续集成、数据库管理生命周期——其中每个短语都足以使有关数据库敏捷思维的讨论听上去比实际复杂。

关键是从小处着手，首先对数据库进行源码控制或版本控制。源码控制本身并不是一种敏捷实践；但它可以促成类似持续集成这样的敏捷实践。没有源码控制，你就无法实现敏捷。实行源码控制，就为实施敏捷创建了条件。

对数据库及应用程序实行源码控制的更大好处是，两者的版本可以同时同步和测试。数据库代码的所有变更都同应用程序代码的变更联系在一起，任何可行的构建都可以任何时候重新生成。SQL Server最有价值专家Grant Fritchey在“ 为什么要将数据库纳入源码控制？ ”一文中写道：

将数据库直接同应用程序一起纳入源码控制可以实现数据库变更和应用程序代码变更的整合，那样，你就总是可以知道，正在部署的数据库代码版本直接对应于正在部署的应用程序代码版本。

部落记忆不是源码控制

部分公司和组织仍然依赖手动的、脚本驱动的流程，他们常常将其称为源码控制。通常，其构建是围绕一个人或一个小团队对数据库的深入理解和以前什么可行（现在可能仍然可行）这样一份记忆。开发人员和DBA直接操作脚本，而不是数据库，数据库变更历史很难维护。

这不是源码控制，而是对源码控制的畏惧。已有的数据和结构必须总是处于保护之下，那样数据才会得到维护，才不会有任何东西丢失。对源码控制的畏惧正是源于这样一个事实。

尽管如此，借助源码控制，多个人或团队能够在同一时间访问代码段或数据库。每个代码段都有版本，这有助于形成分支以及确保不会有任何东西丢失。或者，可以将整个代码集版本化，使开发人员具备部署到已知状态或恢复到先前状态的能力。

同样重要的是，配备一个恰当的源码控制系统，源码控制实践会成为每个人日常工作生活的一个正常部分，而不限于一个人数有限的领域。因此，如果真出现了问题，它们也可以得到快速解决，而不会变成一个潜在的危机。

简洁为美

正如所见，对数据库代码实行源码控制有极大的好处。但如果开发人员和DBA的工作变得越来越复杂而不是越来越简单，那么实行源码控制的好处就不复存在了。

引入一种源码控制工具，迫使开发人员改变工作方式，或者采用不同于现有做法的策略，显然会惹恼别人。同样地，选择一种不同于应用程序源码控制系统的工具会加深而不是减轻DBA和应用程序开发人员之间的分化。

关键是将数据库源码控制集成到现有的开发流程，那样就可以同开发人员已经熟悉的工具和做法保持一致。在SQL Server领域，这不可避免地意味着要使用——最好是在内部——SQL Server Management Studio。

借助一个插件源码控制工具，开发人员可以继续使用交互式开发模型，操作一个“在线”数据库。它将对象创建脚本的源码控制自动化，提醒用户数据库与源码控制版本之间的差异，并且让向源码控制系统提交变更更容易。

随着源码控制成为正常数据库开发流程的一部分，生产力也会得到提升。它节省了时间，使开发人员更不容易忘记向源码控制系统提交代码，减少了任务切换，提高了效率。由于可能有多个团队参与应用程序和数据库开发流程，所以一个库也会让查看已完工任务变得更简单。

可见，随应用程序一起实现数据库源码控制不仅可行，而且带来了许多好处。它在开发、测试和生产环境之间同步数据库结构，减少了有关的工作和错误。此外，它能确保数据库开发团队同其他人就变更进行沟通，并在需要时提供一个可以用于回滚的版本。

当然，它打开了通向真正的敏捷实践（如持续集成）的大门。

仅仅实现所需要的敏捷

关于迁移到敏捷工作方式，最重要的信息可能是你所决定的变革步伐。

一旦配备了源码控制系统，你就可以选择引入持续集成，将数据库变更和应用程序代码一起构建、测试和打包，加速发布，降低部署风险。它不仅可以验证你的数据库结构，而且还可以在真实的测试数据上运行单元测试，并检查数据库变更实际上是否是按照你的意愿部署的。

然后，你可以升级发布管理流程，包括所有可以让生产环境数据库安全高效地变更所需要的更新脚本、变更报告和审核步骤。

这里的关键是自动化，让工具负责处理每个数据库开发人员和管理人员工作列表最底下那些重复、费力且占用大量时间的任务。

所有这一切的自动化可以将DBA解放出来，将更多的时间花在重要的工作上——降低数据库部署失败的风险。这也许并不奇怪，SQL Server Central最近的调查显示，在已经使用像持续交付这样的敏捷实践的公司中，大约有60%的公司变更发布时间降低了；有超过40%的公司变更部署时间降低了；有30%的公司表示，由糟糕的部署所导致的时间浪费减少了。

开始的时候，将数据库与应用程序一起实现源码控制，但最终的好处将远不止于此。

“精益机器”的第二部分将详细介绍数据库开发人员如何从像持续交付和自动部署这样的敏捷实践中受益。