微信号:infoqchina

介绍:有内容的技术社区媒体

数据库持续交付

2014-05-30 15:20 InfoQ

业务需求是变革最显著的驱动力,事倍功半、快速交付是成功的行业先锋与其它公司的区别。

如果竞争对手交付的特性比你更快、质量更高,你最终将失去市场份额。“敏捷开发”的诞生源于快速变化的需求,以有限的资源,应对不断变化的需求,产出有保证的最佳质量。

你再无法等待6个月后的版本;瀑布方法的大版本概念已经过时了。

技术公司和IT部门期待的是敏捷。

接下来就是开发与运维的自然连接,因此诞生了“DevOps”。

要高效地掌握敏捷Spring开发和实践DevOps,你必须实施部署和过程的自动化。否则部署和发布就需要手动的步骤和过程,无法保证可重复的准确性,容易出现人为错误,也无法以较高的频率处理。

持续集成、持续交付和持续部署是常用的原则和实践,用来结构化处理自动化过程,为软件开发、构建、测试和发布过程中的参与者建立基本规则。

衡量持续过程的成功

持续过程带来的成功通常非常明确,主要关注这些领域:

  1. 更快的变更——能够更快反应

  2. 更少的变更回退——更高的代码质量,更短的上市周期

  3. 更多稳定版本——对最终用户来说缺陷更少

  4. 开发和运维间更好地合作(DevOps...

通过将“一切”自动化,并将测试、重点更新和过程移到“上游”,我们看到更好的服务、更高的客户满意度和更好的盈亏底线。

安全的数据库持续交付

数据库部署是非常棘手的;与其它软件组件,如代码和编译过的代码不同,数据库不是文件集合。数据库是我们最有价值资产的容器,包含了我们必须保留的业务数据。它包括了应用的数据,客户交易等。为了促进数据库变更,需要开发临时代码,处理数据库Schema结构(表结构)、数据库代码(过程、函数等)以及应用程序使用的数据(元数据、查找内容或者参数表)的脚本。

通过将数据库对象变更脚本提交到传统版本控制库中实现自动化,这种方法的用处是非常有限的,也缺少灵活性并与数据库本身失去了关联。同时它也可能是不真实的,由于变更冲突容易导致丢失目标环境的更新。对于自动化来说,使用“比较并同步”的工具是有风险的。这两个概念并不兼容,因为它们彼此并不知道对方。

一个简单的自动化过程基于构建一次,多次部署(Build Once Deploy Many system),它看起来是这样的:

提交变更到版本控制库-->构建-->部署测试-->运行单元测试-->部署到下一级别-->运行更多测试-->...-->部署到UAT-->测试-->部署到生产环境

一个构建步骤,对应多个部署和测试步骤,这就是构建一次,多次部署。

尽管它对原生代码的二进制文件有效,但部署数据库却并非如此,因为你不能简单地复制和粘贴,而是要将老版本转换到新版本,同时保持业务数据还存在数据库中。

有很多这样的场景,脚本创建之后,在它被运行之前,目标环境发生了变化。举个例子,在这个过程之外,数据库打了一个关键补丁,或者另一个团队在并行工作。每种情况都打破了预期结果,导致构建一次,部署多次的方法中产生了问题。

[数据库部署,构建一次,部署多次失败]

使用构建和按需部署方法升级数据库,将会按需生成从当前版本升级到下一版本的数据库变更脚本,确保目标状态是最新的,并且是经过验证和考虑的。

成功升级到预产品(Pre-production)后,脚本被保存起来重用,因此生产环境升级是基于在预产品上测试过的脚本。

[构建和按需部署]

自动化的信心

如果对自动化没有信心,就没人会使用它。由于缺少不同的环境间数据库代码冲突的提醒,DBA和开发者很难依赖简单的比较并同步方法生成的脚本。

通过签入代码时进行提醒,以文件为基础的版本控制多年前就已经解决了沙盒、分支并行开发中遇到的同样问题。如果发生冲突,开发者将收到警告,他/她提交的代码自从签出后已经被别人修改。开发者在本地电脑合并变更,然后再签入合并的代码。

而数据库则不同,它并没有保存在开发者的电脑上;代码存在于各种环境中,任何有权限的人都能修改它。当生成变更脚本时,应该使用基线方法(与现代的,以文件为基础的版本工具使用的是相同的方法)解决合并问题。

检查盒子

当我们实施持续交付时,认识到数据库持续过程需要健壮的数据库版本控制、安全的自动化部署和清晰的工作过程,并且过程的自动化将帮助我们定义解决方案的类型。

以下是这些挑战的一些例子,DBmaestro有助于解决这些问题。

  1. 强化数据库版本控制。这能保证所有数据库变更遵循一个强制的文档过程,这样我们就始终知道谁在什么时间,因为什么原因做了什么改变。这是后续过程的基础。

  2. 使用基于任务的开发过程,有助于将每一个引入的变更与变更请求、故障单或工作项关联起来。后期的部署可以依靠这些信息来帮助决定哪些变更需要发布、哪些即将发布以及哪些要推迟。

  3. 基线明确的部署,连接到版本控制工具,分析引入的变更有哪些影响,帮助我们安全地确定应该部署哪些变更。更重要的是,它让我们明确应该取消哪些变更,才不会推翻其他团队部署的重要变更,或者覆盖补丁程序到生产环境中。

  4. 自动化接口(Web-service,命令行API等等)是创建一个和谐过程所必须的,将数据变更的处理作为完整过程的一部分,与Java.Net代码变更的交付紧密结合。能够自动升起红色标记和“停止这一行”是持续过程必不可少的步骤。我们想要的最后一件事是可以随意将变更部署到生产环境,因此当有什么东西不满足我们的安全假定时,应该能够得到警告,这将直接决定我们能够沉睡还是做噩梦。

总结

在各种持续过程中,数据库是一个真正的挑战。对自动化来说,数据库对象变更脚本放入传统版本控制工具或使用“比较并同步”工具,这是效率低下或者风险很高的事情,因为两个概念彼此互不相识。在持续交付和DevOps中,需要更好的解决方案。

数据库持续交付需要遵循变更管理的成熟的最佳实践,强制在数据库上执行单一的变更过程,当融入其他发布过程时,能够处理部署冲突,消除代码覆盖、交叉更新和代码合并的风险。

更多精彩内容,请点击阅读原文。

***********************************

本文来自InfoQ微信公众账号:infoqchina

1、回复“今日新闻”,查看今天更新的新闻;

2、回复“今日英文”,查看今天英文站的更新;

3、回复“文章 +关键词”,搜索关键词相关内容;

4、回复“QCon”,了解QCon大会相关信息;

5、回复“活动”,了解最近InfoQ组织的线下沙龙;

6、回复“架构师”,获取《架构师》下载地址;

7、回复“投稿”,了解投稿和加入编辑团队的流程。

***********************************


 
InfoQ 更多文章 Facebook如何实现PB级别数据库自动化备份 学术派Google软件工程师Matt Welsh谈移动开发趋势 Spotify为什么要使用一些“无聊”的技术? 妹纸们放假了,汉纸们做啥? 大多数重构可以避免
猜您喜欢 思想 | 智能机器实现了简单应用,但依然在等待意识觉醒 【原译】webpack 2和babel 6的tree-shaking 经济学家董藩教授写给女儿的一封信(视频) cSphere创建容器高级选项解释 解决磁盘io紧张的一种临时方法