写点什么

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

  • 2015-10-08
  • 本文字数:3779 字

    阅读完需:约 12 分钟

多年来,敏捷实践携短迭代、快发布、更快推出软件的承诺一直吸引着应用程序开发人员。现在,同样的做法已经进入数据库领域,但是,数据库开发团队该如何采用那些做法,他们应该从哪里开始?在本系列文章的第 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% 的公司表示,由糟糕的部署所导致的时间浪费减少了。

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

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

关于作者

Matt Hilbert是 Redgate 的一名技术作者,有 20 年的工作经验。他为许多世界上最大的技术公司工作过,也为其中许多最小的公司工作过。他特别热衷于研究新兴技术,孜孜不倦地向广大读者解译、解析、解释技术观点,让人们为技术带来的无限可能性而兴奋。

查看英文原文: The Lean Machine: Bringing Agile Thinking to the Database

2015-10-08 05:521986
用户头像

发布了 1008 篇内容, 共 389.4 次阅读, 收获喜欢 344 次。

关注

评论

发布
暂无评论
发现更多内容

人效将是快消品企业未来发展的最大瓶颈

百度大脑

人工智能

CPython 性能将提升 5 倍?faster-python 项目 PEP 659 源码级解读

阿里巴巴终端技术

Python 源码 源码分析 CPython

Android 64位架构适配

百瓶技术

andiod 客户端

架构实战营第 4 期 -- 模块七作业

烈火干柴烛灭田边残月

架构实战营

使用无参数函数进行命令执行

网络安全学海

黑客 网络安全 信息安全 渗透测试 安全漏洞

Scrum Master如何参与每日Scrum(Daily Scrum)

Bruce Talk

Scrum 敏捷 Agile Coach/Facilitate

(1-14/14) 首位销售人员

mtfelix

300天创作 2022Y300P

十大视频场景化应用工具+五大视频领域冠军/顶会算法重磅开源!

百度大脑

Python 为什么不设计 do-while 循环结构?

Python猫

Python

使用Rainbond打包业务模块,实现业务积木式拼装

北京好雨科技有限公司

Hoo虎符研究院|区块链简报 20220117期

区块链前沿News

Hoo虎符 Hoo 虎符研究院 区块链资讯

如何基于知识图谱实体解析技术进行数据优化?

索信达控股

人工智能 AI 知识图谱 数据优化 索信达控股

聚类算法有哪些?又是如何分类?

郑州埃文科技

数据分析 聚类算法

如何处理消息丢失问题?

JavaEdge

1月月更

混沌工程之 Linux 网络故障模拟工具TC

zuozewei

Linux 混沌工程 1月月更

ThinkPHP6和GatewayWorker简单的示例

CRMEB

深入浅出Apache Pulsar(1):Pulsar vs Kafka

云智慧AIOps社区

kafka 云原生 消息队列 kafka运维 Apache Pulsar 消息系统

恒源云(GPUSHARE)_实例关机后如何操作迁移?

恒源云

gpu 运维 实例

政法委跨单位重点人员联防联控平台建设,治安防控系统开发

a13823115807

APICloud 原生模块、H5模块、多端组件使用教程

YonBuilder低代码开发平台

前端开发 APP开发 APICloud 模块 跨端开发

【高并发】导致并发编程频繁出问题的“幕后黑手”

冰河

并发编程 多线程 高并发 协程 异步编程

前额皮质如何影响我们的工作效率?

LigaAI

工作效率 脑科学

网络安全kali渗透学习 web渗透入门 Kali系统的国内源配置

学神来啦

3DCAT荣获2021金陀螺“年度XR行业技术创新奖”“年度优秀VR行业应用奖”两项大奖

3DCAT实时渲染

云计算 教育 VR/AR 渲染 渲染器

Kafka 为什么这么快?多的是你不知道的事

码哥字节

kafka 消息队列 1月日更 1月月更

Go 语言快速入门指南:Go 并发初识

宇宙之一粟

golang 并发 Go 语言 1月月更

打造手淘极简包的轻量化框架

阿里巴巴终端技术

ios android 框架设计 移动开发 包大小

腾讯自选股如何实现单位小时内完成千万级数据运算

ninetyhe

腾讯 海量数据 分布式,

表单数据高级搜索功能设计

全象云低代码

搜索引擎 前端 低代码 搜索 表单

实战 MongoDB Aggregate

PingCode研发中心

mongo pipeline Expression

redis未授权访问漏洞复现

喀拉峻

redis 黑客 网络安全 安全 信息安全

精益机器:将敏捷思维引入数据库开发_研发效能_Matt Hilbert_InfoQ精选文章