数据库 DevOps

在 PlanetScale，我们早期意识到一个事实：数据库领域几乎未受到 DevOps 实践的触及。DevOps 的好处众多，例如更快的产品交付和持续集成，那么为什么我们不希望在数据库中实现这些呢？
DevOps 生命周期：计划 (plan)、编码 (code)、构建 (build)、测试 (test)、发布 (release)、部署 (deploy)、运行 (operate)、监控 (monitor)
当你看到关于 DevOps 的描述时，通常会伴随着一个如上图所示的循环。然而，这种循环主要仅适用于无状态任务（stateless workloads）。
构建 DevOps 工具链允许你利用 GitHub、CircleCI、Kubernetes 和 Datadog 等工具编写代码、构建、测试、部署和监控。在过去十年中，这些工具及类似的解决方案已经在行业中变得非常普遍。然而，数据库却始终没有加入这个生态圈。
在 PlanetScale 出现之前，数据库一直处于 DevOps 循环之外。它像一个不可名状的状态块一样存在，工程师和运营团队不得不谨小慎微地处理它。没有人想过为什么数据库不能成为软件开发流程中既灵活又增值的一部分？

持续部署 (Continuous Deployment)

DevOps 的一个关键部分是能够持续部署代码。这不仅使你的业务能够快速迭代，还意味着你的本地开发环境不会与生产环境相差太远。与其发布标记版本的软件，不如始终处于持续部署的状态。
持续部署代码的问题在很大程度上已经解决了。然而，任何比 UI 更复杂的功能通常还需要在数据库层面进行模式 (schema) 的更改。
在当前的传统数据库生态中，工程师只能手动实施数据库操作，例如模式更改，这些操作通常无法与标准 CI/CD 流程融合。在更复杂或规模更大的环境中，工程师甚至需要为 DBA 团队开工单，以应用模式更改以避免停机或数据丢失。这可能会将流程拖延数周，而原本应该是快速的操作。
与上述 DevOps 循环相比，传统的数据库模式更改流程如下：

PlanetScale 如何实现 DevOps

PlanetScale 创造了一种完全新颖的解决方案：一个可以本地支持 DevOps 流程的数据库。数据库的更改应该具备与代码部署中同样的语义：自动化、安全防护和回滚。
使用 PlanetScale 的数据库 DevOps 流程

PlanetScale 开发分支

在功能开发流程的开端，开发者通常会创建一个 Git 分支来进行代码开发。而在 PlanetScale 中，你可以为你的 Git 分支创建对应的 **数据库分支**，用于充当你的开发环境。PlanetScale 分支本质上是数据库的隔离副本，开发者可以创建它来测试模式更改，而无需担心影响生产环境。这确保了开发者能够基于类似生产环境的环境进行开发，而没有风险。
数据库分支的另一个好处是它是云托管的，这意味着工程师可以共享环境，用于协作或预览。
在 CI 流程中，PlanetScale 也扮演着重要角色。通过 PlanetScale 的 CLI，任务创建分支可以实现自动化，这些分支可以作为隔离测试环境。模式更改可以安全地应用和测试真实数据，而不会对生产环境造成影响。

部署请求 (Deploy Requests)

当你准备好部署时，可以使用 PlanetScale 部署请求 来安全地将模式更改发布到生产环境。部署请求允许你对建议的更改进行评论，要求批准并签署。一旦一切准备就绪，你的模式更改将在线部署到生产环境，而不会锁表。
这一过程可以在无任何手动步骤的情况下作为你的持续部署 (CD) 流程的一部分自动化。如果部署导致错误，你可以立即回滚数据库部署而不会丢失数据，旧版本的模式将会被恢复。