持续交付与数据管理

当我说到：数据管理对于持续交付太重要了，有人可能会感到惊讶。

持续交付是一种敏捷工作的方式，我们应该不断地反思和调整。这是敏捷思维的基本原则，我们必须考虑我们对数据应该如何组织和使用。

首先，如果我们想要能自由地学习和调整，就要考虑出现错误的概率。我们必须努力实现这种自由度，以便当我们的理解发生变化时，可以管理我们对数据的变更。

接下来，我将描述如何采取渐进的方式来管理数据，以及如何自动化数据管理过程，并测试其内容，以便更有信心地确保这些变更在进行时是安全可靠的。

我们讨论数据的版本控制和数据管理。

我们希望对所有内容进行版本控制。本质上，我们是希望控制进入生产环境的每一个细节。

我们希望以小步骤方式进行变更，以便我们在取得进展时，能够学习、适应和了解这些变更的状态。

我们希望测试所有内容，以便了解这些变更并确保它们是安全的。

因此，让我们现在开始进行设计，以便能够支持这种小粒度级别的变更。我们希望对创建的所有代码，以及其他所有东西进行版本控制。如果我们不能做到这一点，那么这就不是真正的持续交付。

在数据上下文中，这是值得考虑的。我们可能希望能够相当明显地变更生产环境中的数据结构或数据类型。

我们希望对数据管理可以支持自动化测试和手动测试，性能测试和数据迁移测试。那么我们应该从哪里开始呢？

我认为从「生产数据」这一点是一个很好的起点。假如我们不确定数据结构是否正确，那么，我希望在一开始时就能够对变更数据结构和数据进行记录。同时，如果我们想要更敏捷地工作，就必须允许数据结构向前演变。

弗雷德·布鲁克斯有句名言：“一旦冻结了设计，它就会过时。”

为了避免设计过时，我们必须允许我们的设计也能随着时间的推移而变化。

所以，如果要让数据结构可以演变，我们必须可能小步迁移数据，才能实现结构的变化。

因此，我们希望：

（1） 能够进行更小的变更，这样可以更容易地管理所有这些东西。

（2） 能够对 DDL 脚本、迁移脚本、增量脚本等进行变更。

（3）  在部署和配置数据时，不需要任何手动干预，实现自动化所有这些步骤。

（4）  创建自动化测试，来验证我们的数据迁移，并使用数据库重构技术。

事实上，我们可以使用原子递增序列来进行版本化管理模式，这样就可以跟踪我们每一次数据变更的顺序。

我们将所需的数据库结构与应用程序存储在一起，并将当前数据库结构模式与支持该模式的数据版本一起存储。

当应用程序与数据存储之间存在明显的关系时，应用程序的特定版本需要与数据存储的特定版本在一起工作，因此需要跟踪这两个版本之间的兼容性关系。为此，可以创建一个表或文档来记录应用程序版本与数据存储版本之间的关系。通过这种方式，我们可以跟踪每个应用程序版本所使用的数据存储版本，以便更好地管理它们之间的关系。

为了更好地管理这种关系，我们可以将数据存储结构保存在与应用程序相同的版本控制系统中，以确保应用程序和数据存储之间的关系得到明确定义。

同时，我们还需要考虑数据本身的变化，随着应用程序和数据结构的开发，每个应用程序和数据结构版本都会有对应的记录。在变更数据结构时，我们需要确保可以迁移所有数据到新的版本。

通过以上这些措施，我们可以更好地管理应用程序版本和数据版本之间的关系，确保它们之间的兼容性，并减少依赖项管理的问题。

想象一下这样的场景：

我们现在要同时变更应用程序和数据存储，我们可以在定义变更的脚本中记录这些被修改的数据存储，并将通过增量脚本捕获变更的方式，将其记录下来。

例如，我们将为此变更创建一个 索引号 76。我们把这些增量脚本保留在相同的版本控制系统中。如果我们再次对数据进行变更，就可以在每次变更时，添加一个新的增量脚本，并给它一个新的索引号。我们将递增地修改数据结构（即从一个版本到下一个版本的变更），并保留所有这些增量变更。

随着应用程序的变更，我们再次记录其与哪个版本进行交互。我们将所有这些变更控制保持在一起，以便于查看。下面就是增量脚本的一个示例。我们会包含一些说明，例如“对数据模式的变更”，并提供一些说明，告诉我们如何迁移数据，如何从先前版本迁移数据到新版本的架构。

在上例中，从上一个版本（例如75） 到下一个版本（例如 76）的过程中，尽管我们必须添加一些迁移测试，但这是值得的。同时，也应该测试迁移脚本的行为，当然不是测试那些数据本身。

所以，我们可以尝试编写某种小型测试用例，该测试将断言这些脚本以您预期的方式迁移数据。您可以将其视为一种数据迁移单元测试。我们也将这些测试用例再次存储在相同的版本控制系统中。通过这种方式，我们可以最大限度地减少依赖项管理问题。

很明显，随着应用程序的不断演进，我们会有很多脚本，这些脚本知道现在数据存储中，关于数据结构的最新情况。当需要部署时，我们就可以开始使用这些信息了。

当我们将系统部署到测试环境时，测试环境会告诉我们当前数据存储中的版本是什么。请记住，在部署新版本之前，我们的部署工具应该检查新的发布候选版本。在本例中，这个发布候选版本要求的数据存储为版本80，而它当前是版本79。这意味着我们将运行增量迁移脚本，将其从版本79移动到版本80。

现在，我们运行这个脚本，来迁移生产环境中的数据和结构。我们可以在数据库中记录当前的这个版本号。它会一步步地逐步应用将生产数据存储移动到新版本所需的所有增量脚本。我们对数据库的结构或内容所做的每一次变更，都是用这些增量脚本中的某个版本实现的。

假如我们对执行这一操作的可靠性感到担心，我们还可以多做一步，即：同时编写一个回滚脚本，用来撤消其对应的变更。这样一来，每当我们需要变更数据存储时，我们都会编写一个向前更新和向后回滚恢复的脚本。此时，我们就有能力将任何候选发布版本的任何版本部署到任何环境中，它即可以向前更新（或者向后回滚）到任何需要的点。这给了我们很大的灵活性。

当然，这种方法也有缺点。如果工作非常出色，你可能就不会有机会经常演练你的回滚脚本。所以，大多数团队通常会得出结论：写回滚脚本，可能比他们想做的工作多，而且不够可靠。他们会更相信自己能随着时间的推移向前滚动。但这肯定是一种有用的方法，因为你对所有这些脚本都越来越有信心了。

你的部署工具将执行这些方法，应用适当的增量，向前或向后滚动到正确的修补程序级别。这并不总是足够的。因为可能会有一些过于昂贵的变更在部署时执行，尤其是你在快节奏的持续交付环境中操作。所以，除了这些部署时间方法外，还有其他令人感兴趣的策略。我们以后再讨论。

我如何才能实际体验上面的整个工作流程呢？

如果你希望在一个轻松的环境中，真正了解并学习上面这些持续交付的技术，可以选择我的在线训练营。该训练营不但有持续部署技术的相关理论与技术讲解，同时还会通过一个可以真实运行的 Web 应用程序开发，带你实地体验 ATDD / TDD，持续集成，持续部署，功能开关的使用，数据库结构的变更。

乔梁老师开课啦~视频课程《持续部署训练营（Python版）》，原价1099元， 限时特价499元

你的软件开发效率够高吗？质量够好吗？你的团队多长时间才能向用户实时推送一个生产变更？你的软件在发布时，你是否因担心软件交付质量而感到压力倍增？你是否遇到过部署失败，甚至导致停机的情况？持续部署可以帮助你消除软件交付的痛苦，让你能专注于为客户高价值的需求，而不会因为这些交付执行类问题而花太多精力。本课程通过学练结合，理论结合实战，让你体验如何使用构建-测试-部署管道，进行持续部署。并练习如何在有效监控部署的同时，逐步发布功能特性，并作数据库结构变化。

（扫码订阅）