Datical为数据库添加持续交付能力

数据库 持续集成

摘要： 数据库发布自动化提供商Datical发布了新版本Datical 5。该版本实现了一种集中命令中心，提升了数据库版本的可见性，支持开发人员在无需手动应用代码更改的情况下，管理并重做（rework）数据库代码更改。此外，该版本还增强了数据库凭证和可审计性的安全。

作者： Helen Beal

正文：

数据库发布自动化提供商Datical发布了新版本Datical 5。该版本实现了一种集中命令中心，提升了数据库版本的可见性，支持开发人员在无需手动应用代码更改的情况下，管理并重做（rework）数据库代码更改。此外，该版本还增强了数据库凭证和可审计性的安全。

Datical 5提供了一组仪表板和管理界面，可供开发人员和数据专家访问。仪表盘上展示了数据库版本的状态和进展速度，管理界面则用于跟踪数据库在整个发布流水线中的更改情况。它还支持在强制执行审计和合规性规的同时，对部署变更到环境之前模拟变更所产生的影响。

新版本解决了在数据库迭代开发中存在的一些挑战，允许开发人员检入需重做的数据库代码更改。当前，重做数据库更改是一项具有挑战性的工作。因为一旦应用发生更改，数据将即刻被添加、修改、重新组织或删除。要重做更改，数据库管理员必须手动地撤消以前的更改。这增舔了一部分额外的工作，并对应用的发布过程给出了一些潜在的限制。

Datical 5可自动回退不必要的数据库更改，并应用更新后的更改。由于缺乏统一的标准和控制，管理数据库环境凭证和访问很有可能是一个高风险的流程。新的集中式凭证存储，提供了一种管理整个企业数据库凭证的标准方法。它还可处理利益相关者的访问控制，提供对集中管理界面的适当访问，从而提高数据的安全性。这有助于组织用户，并强制执行部署状态查看或数据库更改的相关权限。

正如Eduardo Piairo撰写的“将数据库更改添加到部署流水线中的原因及做法”一文中所说的：

数据库和应用应并存于同一部署流水线中。换句话说，二者应分享同样的开发生命周期。但应区别对待数据库开发和应用开发。

Piairo建议，数据库部署应使用一种代码驱动的方法：

如果使用脚本实现所有的数据库更改，那么就可以对数据库更改应用源代码控制，并且可将持续集成和持续交付活动包括到数据库开发中。也就是说，数据库更改可以参与到部署流水线中。

Piairo还列出了在自动化数据库部署中应采取的步骤：

第一步是使用脚本实现数据库更改。在一般情况下，该步骤是手工完成的。下一步是构件（artefact）的构建和验证，构件中包括了数据库更改。这一步应实现完全的自动化。换句话说，我们需要使用脚本实现构建软件包、运行单元测试和集成测试、将软件包发送给构件管理系统和（或）发送给部署服务器或服务。正常情况下，构建服务器缺省包括了上述步骤。最后一步是在目标服务器或数据库中实现数据库更改的自动化部署。和前面的步骤一样，你可以使用部署服务器的内置选项，也可以构建自己定制的脚本。

Datical的高级产品市场经理Sanjay Challa在他的博客帖子“使用Jenkins推送数据库更改存在什么问题？”中指出：

数据库更改当然可以提交给源代码控制。这些脚本可从源代码控制中检出，并使用持续集成工具打包到构件中。所生成的构件可以推送到构件仓储中，并在仓储中使用发布自动化工具，随发布流水线部署到环境，直至生产环境。

But Challa进而建议，应慎重使用该方法：

有必要提醒大家，数据库是具有状态的。因此，必须要慎重管理数据库更改，因为我们并不想破坏数据库的状态。尽管可以使用更改的版本覆盖应用的旧版本而实现替换，但是这种简单的做法并不适用于数据库。一个不良的数据库版本，可能会对企业造成不可恢复的数据损失，也可能导致应用大量停止服务。和大多数应用可执行文件一样，根本不可能“吹干净”旧版本的数据库。然后用更新后的版本覆盖它。

根本上讲，如果仅依靠构建、配置和发布自动化工具来管理数据库部署，那么会使数据处于风险之中。考虑到不良更改的后果，数据库更改通常单独使用手动过程处理。组织的运行将会继续维持手工数据库更改过程所固有的一些特点，例如应用发布速度较低，代码质量较低等。最后一点，如果单纯依靠构建和发布自动化工具，应用和数据库更改将永远不会以相同的速度通过发布流水线。

Challa解释说，为使数据库更改通过应用代码所历经的同一个统一的发布流水线，需要一系列特性的支持。通常需要重做数据库更改，并且由于需要保持数据库的状态，因此相比起重做任何其他类型的代码，重做数据库更改需要做更多的工作。通常，DBA必须手动完成数据库环境的恢复，这样开发人员才能重做更改。如果没有手动撤消需重做的更改，那么会在较低层级的环境中将会执行有差异的前滚，进而有差异的更改将会应用于未受初始更改影响的较高层级环境。这破坏了DevOps“一次构建，多次部署”的理念，因为较高层级的部署与较低层级的部署间存在不一致。

当开发人员可以像处理应用代码一样处理数据库代码，并将更新后的数据库版本更改检入源代码控制时，这时可以使用一种工具去智能地清理较低层级的环境，在其中生成旧版本更改，并应用更新后的版本（并将更新后的更改正确地应用于从未受到旧版本更改影响的更高层级环境）。这将降低了数据库状态受损的风险，去除了手动作业，使得一致性构件可通过流水线得以部署。

Challa接着解释说，数据库代码验证通常是一个完全手动的过程，它不会通过我们在持续集成或交付流水线中所期望的自动化测试。Datical提供的Dynamic Rules Engine解决了这个限制，它允许组织编撰标准和最佳实践，对数据库代码做自动验证。它使用的是基于对象的规则引擎，而不是简单的正则表达式引擎，因此可以实现功能性规则（例如，限制每个表的索引总数）。这去除了手动作业，并可对提交源代码控制的数据库更改做出快速反馈。Datical的Change Management Simulator通过构建目标数据库的内存模型，将建议更改应用于模型中，进而验证模型的最终状态是否符合预期。

Datical 5当前发布的是Beta版，GA版计划于2018年第二季度发布。

查看英文原文： Datical Adds Continuous Delivery Capabilities for the Database