在深入研究数据库 DevOps 之前，先回顾一下什么是 DevOps。它没有统一的定义，但我们知道它起源于软件开发方法与部署和运维的结合。
大约 2007 年和 2008 年，软件开发和 IT 界人士提出了这样的担忧：两个行业的分离，即编写和创建软件与部署和支持软件的人员完全分离，正在给行业带来致命的功能障碍。
DevOps 的目的是，通过共享所有权、工作流自动化和整个软件开发生命周期（SDLC）的持续反馈回路，打破开发者和运维人员的隔阂。而数据库 DevOps 是更广泛的 DevOps 框架中的一个专门子集，侧重于与数据库相关的活动。
数据库 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 2.22.1 - SQL 编辑器展示更丰富的 Schema 信息
Bytebase 签约美宜佳，助力便利店连锁巨头规范化数据库变更及访问流程，确保安全及合规
