共计 3645 个字符，预计需要花费 10 分钟才能阅读完成。
最近 Reddit 的 r/golang 下有人问了一个如何做数据库 schema 变更的问题，不到一天，就有了超过 40 条回复。
数据库 schema 变更始终是让程序员头疼的问题，但又不得不面对，毕竟业务要倒退，产品要迭代，增加新的性能往往须要去批改数据库的构造，比方增加一个新的字段来保留新的信息，那么这就波及到数据库 schema 的变更。
先看提问者的 2 个问题：
问题 1 – 短少变更的可见度
因为可能就开发者或者 DBA 间接连到数据库，就执行了变更语句，具体执行了什么语句，什么时候执行的这些只有当事人本人晓得（或者说当事人回过头来也可能遗记了）。
问题 2 – 保障变更的唯一性和排他性
一个利用通常代码会部署多个正本，但都连着同一个数据库。从提问者的形容看，他们以后是在新的代码版本启动时，去尝试变更数据库的。那么问题来了，当多个新代码版本的正本同时启动时，到底如何保障只有其中一个正本能够对数据库进行变更，而其余正本先期待着呢。
提问者最初也在问有没有举荐的变更最佳实际和工具，能够用于生产环境。从最佳实际角度，次要就 2 点：
- 像看待代码变更一样看待数据库变更
- 把代码变更和数据库变更拆散
而 Bytebase 就是联合这套最佳实际的数据库变更工具。
像看待代码变更一样看待数据库变更
咱们先来看一下典型的代码变更流程：
- 在 GitLab / GitHub 这样的代码平台提交变更申请，GitLab 里叫 MR (Merge Request)，GitHub 上叫 PR (Pull Request)。
- 如果有配的话，MR / PR 会先通过一系列的主动检察，比方最简略的比方代码是否能够编译，是否合乎编码标准，以及一系列的自动化测试。
- 会有一个或多个评审人对代码进行审核 (Code Review）。
- 审核通过后，代码就提交到仓库了，提交历史也被记录了一下。
- 通过手动或者主动的流程，代码会被打包成一个新版本，业余的术语叫做制品（Artifact）。
- 代码部署零碎会把新版本依照事后配置的流程，逐步部署进来。通常先部署到测试环境，在测试环境里，会运行一些集成测试，也可能会有 QA 团队进行手工测试。在测试环境通过后，就会部署到预发环境，在预发环境验证后，最终会部署到生产环境，当然在生产环境，往往也会一点点的逐渐更新，也就是所谓的灰度公布。
后面介绍的也就是大家当初所熟知的利用 CI/CD 流程，演绎进去不长，但其实也是花了业界 20 多年才摸索出了这套现在约定俗成的计划，解决了代码变更和公布里的协同，可见度，可靠性，效率等一系列问题。
而数据库的变更因为波及到数据也就是状态（state）的变更，尽管流程上能够借鉴代码变更的思路，但还是更加简单的。Bytebase 就是这样一套把代码变更的流程引入到数据库变更的工具。
可视化的变更审核界面
Bytebase 提供了可视化的变更审核界面，开发者和 DBA 能够在同一个界面上对于数据库变更进行合作。
主动 SQL 审核规定
Bytebase 提供了总共 100+ 多条主动 SQL 审核规定，毋庸 DBA 染指，就能前置地检察开发者提交的语句是否符合规范。这里能够进一步浏览来自用户的案例分享「SQL 审核案例分享回顾|如何搞定 300 个研发」
数据库代码化 Database as Code
Bytebase 是数据库代码化的布道者和领导者，如果在 Google 上搜寻 Database as Code 的话，Bytebase 对于 Database as Code 的论述也是排名第一的，当先于像 Liquibase，DBmaestro 这样的老牌厂商。
Bytebase 是目前业界惟一提供了点击式的配置交互，相似于 Terraform Cloud / Vercel 这样的体验，就能够配置好 GitOps 工作流。配置实现后，研发还是在他们相熟的代码仓库中提交数据库的变更文件，在审核实现提交到代码仓库后，会主动触发在 Bytebase 这边的部署流程。
批量变更（企业版性能）
变一个数据库曾经不容易了，同时变一堆数据库呢？这个需要其实在企业里很常见，比方不同研发环境就对应着不同的数据库；SaaS 公司，会给每一个租户调配独立的数据库；游戏公司，不同的服务器背地对应的其实也就是不同的数据库；因为容灾或者数据合规的要求，不同地区也会部署各自的数据库；当然也不能忘了互联网常见的分库分表场景。这些数据库的构造都是雷同的，所以一旦变更，也要是能保持一致。Bytebase 就专门针对这种场景设计了批量变更的能力，像下图所示，展现了变更一次医院 SaaS 零碎的数据库，针对不同的医院租户在不同环境上变更的一个二维停顿图。
自定义审批流（企业版性能）
自从 1.16.0 版本，Bytebase 也推出了基于危险模型的自定义审批流。用户首先定义数据库操作的危险等级，而后再依据不同的危险等级来配置绝对应的审批流。
审批节点能够自定义，因为 Bytebase 有独特的我的项目概念，所以说在审批节点上，还能够指定具体该项目标 DBA，测试负责人这些。
Image
把代码变更和数据库变更拆散
一个利用有两大部分组成，一块是代码，一块是数据，前者业余的术语叫无状态（stateless)，后者则对应有状态（statefull)。无状态的代码变绝对好解决，因为如果变更有问题，间接回滚就完事了。但有状态的数据变更就难多了，变更的时候要思考是否会把数据库锁住导致整个服务的不可用，回滚也不是那么好弄的，因为有脏数据的问题。
小团队起步时，通常会把数据库变更和代码变更放在一起，但就像那个 Reddit 提问者遇到的一样， 规模下来后就会面临问题 ：
- 当变更出问题后，可控力很小。应用程序将无奈启动，这须要人工干预。
- 一些变更可能须要很长时间能力实现，这意味着在部署新版本公布时须要停机。
- 不适宜于有多个服务器实例拜访同一数据库的利用。因为任何一个服务器实例都能够执行变更，而且须要额定的锁机制来协调变更（就是 reddit 提问者提到的那个问题）
- 不适宜有专门的 DBA 或平台工程团队来中心化治理数据库的团队合作模式。集中的 DBA 或平台工程师不晓得什么时候产生了变更，他们只会在收到监控零碎告警后，而后破费大量的精力去诊断后，才发现是由一个利用团队莽撞的变更引起的。
有状态的数据和无状态的代码是两个齐全不一样的物种，针对代码的变更公布，有 GitLab / GitHub + Octopus / Jenkins 这样的集中式 CI/CD 平台，而针对数据库的变更公布，Bytebase 起到的就是相似的作用。
所以 Bytebase 也把本人称为数据库届的 GitLab，承当了 Database DevOps 的职责。 咱们也像 GitLab 一样，采纳了相似的开源策略，也同时既有托管的 SaaS 服务，也反对私有化部署。
Image
升舱的免费版，让更多团队能够进行平安高效的数据库变更
市面上也有像 Yearning, Archery 这样集体保护的社区我的项目，而 Bytebase 走的则是商业化路线，有残缺建制的产研团队。Bytebase 之前也提供免费版，但因为能力上的限度，使得许多团队有所顾虑，还是采纳了社区里完全免费的计划。于是在上周，咱们进行了 Bytebase 有史以来最大的版本性能调整，次要是针对 Bytebase 免费版的定位进行了调整，从定位于服务个人兴趣我的项目以及团队产品验证，调整为了能够笼罩大多数研发团队中心化治理数据库生命周期的所有外围场景。具体到性能点上， 免费版的性能失去了大大的加强 💎
- 原本只存在于付费版的 RBAC 性能移到了免费版。
- 100+ 条的主动 SQL 审核策略全副凋谢给了免费版。
- 不再有 10 个用户，10 个实例的限度，而是有限用户，20 个实例。
相应的，也是因为免费版也具备了足够服务团队的产品能力。所以原本付费的团队版名字就不那么贴切了，所以咱们也把原本的团队版名字改成了专业版（Pro）。
这次调整的底气，也是因为通过 2 年多的开发，咱们也构建了足够的产品性能梯度，能够在提供笼罩外围场景的免费版根底上，还能进一步提供差异化的性能点，提供给咱们的企业级用户。比方单点登录，DBA 工作流，自定义审批，批量变更，环境分级，数据脱敏，访问控制，水印，审计日志，读写拆散等都是专门提供给咱们企业级用户的能力。
![Uploading file…]()
Bytebase 作为一款 infra 层的开源工具，从第一天起的定位就是做一款全球化的产品。事实上，目前 Bytebase 海内的整体营收也高于国内。只有开发利用，就须要和数据库打交道，不限行业，不限地区。而 Bytebase 就是要帮忙寰球各地，来自不同行业的研发团队一站式治理云上云下，不同云之间，不同数据库的变更，查问，平安，治理四大问题。
就像提到代码托管，大家会想到 GitLab / GitHub，提到监控仪表盘，就是 Prometheus / Grafana，提到多云治理，就是 Terraform。而咱们将要变成的事实，就是当大家提到数据库的开发治理时，想到的就是 Bytebase😇。
💡 你能够拜访官网：https://www.bytebase.com/，收费注册云账号，立刻体验 Bytebase。
