数据库更改是应用程序开发过程中一个棘手的部分：它通常涉及来自不同环境的多个数据库和跨团队协作，此外，数据库是一触即发的。这让我们开始思考：我们能否像对待应用程序代码一样对待数据库？DORA（DevOpsResearch&Assessment）指出，将数据库工作整合到软件交付过程中，对持续交付有积极的贡献。是时候让数据库成为CI/CD周期的一部分了。但是它是如何工作的呢？数据库CI/CD的关键要素要回答“how”，我们首先需要梳理一下典型的数据库变更工作流程。在SQL语句可以安全地应用于数据库之前，有两个关键步骤：检查和更改。1.SQLReview这一步是为了确保变更：业务逻辑被准确执行；遵循数据库设计最佳实践；在这里，开发人员通常负责前者的任务，而DBA负责后者。DevOps哲学旨在通过集成Ops和Devs来解决这个问题。现实情况是，当组织中有DBA时，很难直接合并两个团队。一种可能的解决方案是保留DBA的任务，同时让开发团队能够预审SQL。这种左移方法可以显着降低发布延迟的可能性。此外，如果组织中没有DBA，则更重要的是授权开发团队以确保SQL不会对数据库造成严重破坏。2.SQL更改执行此步骤以确保语句正确执行。我们不希望出现错误的数据库连接、权限不足、对象名称冲突或基本语法错误。执行所有计划的语句。当需要执行的脚本较多，或者有多个目标数据库需要批量执行时，可能会出现遗漏。变更执行流程不应影响业务。长时间耗尽硬件资源和锁定表对公司来说并不愉快。为了避免与更改相关的错误，减少手动方面也很重要：自动化的事情越多，发生错误的机会就越少。预配置的管道自动将SQL应用于数据库？听起来不错。为避免对常规业务运营产生负面影响，应采用各种零停机更改技术，尤其是对于具有大型数据集的数据库。因此，实施数据库CI/CD的关键要素应该使开发团队能够执行SQL审查并简化SQL更改的推出。使用VCS集成进行SQL审查和更改部署让我们首先探讨如何让开发团队自行执行SQL审查。很少有开发人员是审查SQL语句“模式正确性”的专家，即使对于高级DBA来说，手动检查也可能非常低效且容易出错。幸运的是，业界已经通过集成不同的SQL检查规范创建了各种自动化审查工具。然而，这些工具有一个共同的问题——它们都是为DBA设计的。一方面，这些工具往往需要较高的数据库操作权限，不适合开发者直接使用。另一方面，开发人员拥有自己的IDE，而单独的外部仲裁器是他们最不需要的东西。想象一下当您必须在多个工具之间复制和粘贴代码时会有多糟糕。那么一个对开发人员友好的SQL审查工具应该是什么样子的呢？我们通常在版本控制系统(VCS)上执行传统的代码审查过程，SQL也应该如此。因此，应该将SQL审查工具集成到代码审查工作流程中。启用后，当您在GitHub上提交PR时，将触发GitHubMarketplace上可用的SQLReviewAction。让我们看看如何实现简化的SQL更改推出。独立的SQL部署工具并不少见。这些工具通常手动上传SQL脚本，通过批准流程继续部署，然后在部署完成时提供反馈。该模型准确地描述了开发人员和DBA如何独立工作，碎片化的流程是延迟发布的最常见原因之一。毕竟，当您不断地在多个系统之间手动移动SQL脚本时，谁能保证事情永远不会出错？我们需要一个更高效和自动化的发布流程。让我们回顾一下应用程序代码的经典CI/CD工作流程：提交更改>代码审查>合并分支>自动构建>自动部署。既然我们已经在GitHubActions上实现了SQLReview，为什么不能将其包含在后续的rollout流程中呢？好吧，是的，我们可以！用于数据库CI/CD的SQL更改推出工具应该能够与VCS集成。一旦你的SQL脚本被审查并合并到目标分支，发布过程就会被触发，脚本会自动推送到Bytebase。当然，DBA可以在对目标数据库执行SQL之前执行另一次完整性检查。完整的数据库CI/CD工作流程这里，我们展示了一个完整的数据库CI/CD工作流程：开发人员创建一个包含SQL迁移脚本的MergeRequest/PullRequest；自动触发SQLReviewAction对SQL进行审查，并提供建议协助代码审查；在几次可能的迭代之后，团队负责人或开发团队的其他同事批准更改并将SQL脚本合并到一个分支中；合并事件自动触发Bytebase中的发布管道并创建Issue工单；（可选）DBA或指定的审阅者可以通过Bytebase的内置UI审阅更改脚本；批准的脚本根据配置的推出阶段逐步执行；应用更改后，最新的数据库模式会自动写回代码存储库。这样，开发团队始终拥有最新架构的副本。此外，他们可以根据最新的模式更改配置下游管道；确认迁移并继续进行适当的应用程序部署。此工作流程非常适合现有的CI/CD流程，并且对开发人员来说很自然。精明的读者可能已经发现了描述为具有里程碑意义的文章进化数据库设计的实现的步骤。
