Database as Code 分析

在讨论数据库作为代码之前，让我们先讨论一下更一般的概念，即配置作为代码(CaC)。CaC是在源代码存储库中管理配置资源的实践。典型的配置资源包括：

• 基础设施配置，如计算(VMs)、网络资源（负载均衡器）。由于像HashiCorp Terraform和AWS CloudFormation这样的工具，这被广泛称为基础设施即代码(IaC)。
• 监视和警报配置。
• 访问控制策略。
• 持续集成(CI)/持续交付(CD)流水线配置，如GitHub Actions、GitLab CI。
• 功能标志。

最后但并非最不重要的是，我们今天的主题，数据库模式，又名数据库作为代码。

对于某些配置资源类型，在代码存储库中管理它们已经成为事实上的标准，例如使用HashiCorp Terraform管理基础结构，使用Prometheus管理监视/更改配置。
另一方面，对于其他一些配置资源类型，如数据库模式，在代码存储库中管理它们还没有变得那么流行。一个证据是数据库，因为代码还没有收到自己的维基百科页面。
与管理应用程序代码一样，管理应用程序数据库模式也是软件开发过程中的常规活动。在谈到如何演化数据库模式的实践时，有3种粗略的方法：

• 对于某些配置资源类型，在代码存储库中管理它们已经成为事实上的标准，例如使用HashiCorp Terraform管理基础结构，使用Prometheus管理监视/更改配置。
• 另一方面，对于其他一些配置资源类型，如数据库模式，在代码存储库中管理它们还没有变得那么流行。一个证据是数据库，因为代码还没有收到自己的维基百科页面。
• 与管理应用程序代码一样，管理应用程序数据库模式也是软件开发过程中的常规活动。在谈到如何演化数据库模式的实践时，有3种粗略的方法：

优点

业界已经达成共识，以代码方式进行配置优于基于UI的方法，以代码方式管理数据库也不例外。在我们看来，数据库作为代码有3个吸引人的优点：

• 利用现有的代码存储库基础结构并避免重复工作。我们得到的功能，如代码版本/分支，代码搜索，代码审查，通知等免费。像Gitlab/GitHub这样的产品已经在这些领域投入了巨大的努力。
• 与持续集成(CI)和持续交付(CD)DevOps工作流保持一致，通过重放存储在存储库中的模式迁移文件来自动化准备本地/测试数据库的过程。
• 拥有单一真实源(SSOT)，它是存储在存储库中的数据库模式文件。使用SSOT，我们可以在不连接到生产DB的情况下进行漂移检测、分析数据库模式（否则这将很困难，因为生产网络通常与开发网络隔离）。

不足

老实说，从纯技术的角度来看，数据库作为代码的方法没有什么缺点。
实际上，每个Google工程团队都在代码存储库中管理数据库模式，并且它已经为他们服务了10年以上。
与其他方法相比，这里的主要障碍仍然是学习曲线和遵循最佳实践的工程规程。平心而论，任何需要谷歌工程水平的实践都有点牵强。

最初难以设置

1. 团队需要找出如何组织迁移文件来管理不同环境下的许多数据库。
2. 要设置提交的迁移文件触发模式更改的自动化工作流，需要通过OAuth获得VCS实例根访问权限，在VCS项目中设置适当的webhook，观察正确的目录等。除此之外，团队还可以定制规则，比如只允许某些环境中的数据库模式自动更改。

过程变慢，没有连续的正反馈回路

通过数据库将更改作为代码应用肯定比直接将更改应用到数据库需要更长的时间。即使是纯基于UI的SQL审查过程也感觉更加方便。另一方面，尽管我们从风投获得了诸如版本控制之类的有用特性，但它需要更多的工作来释放真正的力量：

1. 只有当代码存储库和数据库服务器之间有更深入的集成时，才有可能实现漂移检测之类的功能，前者存储代码版本控制信息，后者存储模式信息和模式版本历史。
2. 除了数据库和代码存储库之外，还需要其他高级开发概念来为协作开发工作流建模，以交付易于使用的解决方案。
3. 要构造一个真正自动化的数据库CI管道，不仅需要重放迁移模式文件，而且需要构造测试数据。这通常需要与应用程序逻辑集成。

不友好的开放源码数据库

核心特性方面，MySQL和PostgreSQL都是非常有能力的数据库。然而，与专有的相比，它们在操作上不太友好。例如，这两个数据库都没有任何内置的模式版本控制支持，这反过来使得围绕它们构建良好的工具变得更加困难。

Bytebase-使数据库模式管理民主化，特别是将数据库作为团队代码

我们在Bytebase的团队已经在数据库方面工作了10年以上，并在Google Cloud SQL和蚂蚁集团OceanBase管理了一些世界上最大的数据库团队。我们构建Bytebase是为了解决阻止团队采用更好的实践来管理应用程序数据库模式的障碍：
我们为团队提供了一个基于Web的控制台，以便在与数据库相关的任务上进行协作。
我们提供了一步一步的点击向导，让用户将数据库设置为代码（如果您还在观望，我们还提供了基于UI的SQL审查解决方案）。
我们设计一流的模型，如项目、环境、实例、数据库，以帮助团队采用管理数据库模式的良好实践。
我们将所有与模式变化相关的活动如运行状态和历史、模式迁移历史等表面化，使用户能够在使用系统时得到持续的积极反馈。

还有其他的特性我们没有空间在这里涵盖，我们正在积极地工作添加更多的特性。我们当前的目标是使团队的应用程序数据库模式管理民主化，就像GitLab/GitHub使源代码管理民主化一样。我们从解决MySQL和后来的PostgreSQL开始，这是当今最流行的两个开放源码数据库系统。