什么是数据库 DevOps？

原文地址 https://www.bytebase.com/blog/what-is-database-devops/

在深入研究数据库 DevOps 之前，先回顾一下什么是 DevOps。它没有统一的定义，但我们知道它起源于软件开发方法与部署和运维的结合。

大约 2007 年和 2008 年，软件开发和 IT 界人士提出了这样的担忧：两个行业的分离，即编写和创建软件与部署和支持软件的人员完全分离，正在给行业带来致命的功能障碍。

DevOps 的目的是，通过共享所有权、工作流自动化和整个软件开发生命周期（SDLC）的持续反馈回路，打破开发者和运维人员的隔阂。而数据库 DevOps 是更广泛的 DevOps 框架中的一个专门子集，侧重于与数据库相关的活动。

数据库 DevOps 中的角色

开发者和 DBA 是数据库 DevOps 中的两个主要角色。他们的工作重点不同，甚至有些冲突：

开发者：尽快构建并交付。
DBA：防止数据库中断。

一种典型的数据库 Schema 变更工作流

开发者在本地集成开发环境上开发功能，将 Schema 变更应用到本地数据库，并在本地进行测试。
开发者通过 Jira 等工单系统提交 SQL 更改请求。
DBA 审查工单，并与开发者交换意见。
DBA 使用 SQL 客户端离线发布变更。
多次重复步骤 2 ~ 5，在 UAT、Staging 和 Prod 环境中逐一执行变更。

缺乏统一的工作空间

开发者和 DBA 在进行数据库变更时会在不同的工具间跳转。开发者从本地集成开发环境中复制 SQL 语句，粘贴到 Jira 中审核。审核通过后，DBA 将 SQL 语句从 Jira 复制到本地 SQL 客户端以应用更改，然后，DBA 更新 Jira 工单并通知开发者。

缺乏自动化

手动复制 SQL 语句 -> 粘贴错误的 SQL 语句。
手动审核 SQL 语句 -> 审核延迟和忽略缺陷。
手动部署 SQL 语句 -> 应用到错误的数据库（臭名昭著的 DROP PROD 意外）。

这些并不罕见。DBA 的人数总是少于开发者，许多工程组织甚至没有专门的 DBA 角色，而只是指派某人担任 DBA。

通往数据库 DevOps 之路

统一的工作空间

由于 GitLab、GitHub、PagerDuty 和 Datadog 等平台等工具的显著进步，DevOps 已成为现实。这些平台允许开发者、发布工程师、运维工程师和 SRE 在一个地方进行协作。数据库 DevOps 也需要一个整合的平台。

最起码的是覆盖变更流程。这可以通过采用 GitOps 这一典型工作流来实现：

开发者在 GitHub 等 VCS 中提交 SQL 变更脚本供审核。
审核通过后，合并脚本。
脚本合并后，会触发 CI 管道来安排部署。

这利用了 VCS 来请求、审核和版本化 SQL 语句。不过，即使有 GitHub Actions、GitLab CI 这样的内置 CI，VCS 仍然依赖外部 CD 系统来部署数据库变更。此外，除了变更任务，另一个常见的数据库任务是查询数据库。VCS 没有交互式界面允许用户发布 SQL 语句并获取结果。

真正的综合数据库工作空间（如 Bytebase）应涵盖「写入」（更改数据库）和「读取」（查询数据库）路径。它必须提供请求、审核和部署数据库变更的工作流，以及查询数据库的交互式 SQL 接口。

自动化

自动化有多种应用：

采用 GitOps 来简化从合并到部署的数据库变更过程。
连接 SQL，自动检测 anti-SQL 模式。
记录变更历史并自动准备回滚。
在操作事件发生时发送通知。
通过 API 自定义自动化。

Bytebase 可通过 GitOps、SQL 审核、内置回滚、Webhook 集成和 API 自动执行数据库任务。

总结

数据库 DevOps 强调将数据库整合到 DevOps 生命周期中，促进开发、运维和数据库团队之间的协作。通过利用自动化工具和实践，团队可以简化数据库部署和查询流程，减少人工错误并提高一致性。这种方法不仅能加快交付周期，还能确保数据库开发生命周期与应用开发生命周期无缝集成，促进形成责任共担、持续改进的文化。

💡 更多资讯，请关注 Bytebase 公号：Bytebase