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

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

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

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

数据库 DevOps 中的角色

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

• 开发者：尽快构建并交付。

• DBA：防止数据库中断。

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

1. 开发者在本地集成开发环境上开发功能，将 Schema 变更应用到本地数据库，并在本地进行测试。
2. 开发者通过 Jira 等工单系统提交 SQL 更改请求。
3. DBA 审查工单，并与开发者交换意见。
4. DBA 使用 SQL 客户端离线发布变更。
5. 多次重复步骤 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 这一典型工作流来实现：

1. 开发者在 GitHub 等 VCS 中提交 SQL 变更脚本供审核。

2. 审核通过后，合并脚本。

3. 脚本合并后，会触发 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