PlanetScale 如何释放开发者生产力
你和你的团队可能花费了大量时间寻找并招募顶尖的软件工程师，但他们是否达到了理想的生产力水平？越来越多的组织开始关注如何提高开发者的生产力，我们认为这一过程始于你的数据库。这份指南将帮助你了解是什么拖慢了开发节奏，为什么这很重要，以及如何通过更好的数据库释放开发者的生产力，从而提升你的组织的创新能力。
为什么开发者的工作会被拖慢？
即使你雇佣了最优秀的工程师，如果团队的流程和技术栈不够高效或过时，依然会拖慢节奏。
技术债务
技术债是任何公司的必然部分，但过多的技术债和缺乏清晰的解决方案会直接浪费宝贵的开发时间。
团队间的摩擦
负责不同技术栈部分的团队之间的协作不畅可能导致代码停滞。例如，等待数据库管理员 (DBA) 批准架构更改或执行迁移可能代价高昂。
低效的开发流程
构建、测试和部署代码的低效流程会让工程师把时间浪费在那些无关客户需求的地方。
工具过于笨重
相比现代化工具，一些笨重的工具可能让本来可以快速完成的工作耗费更长时间。
本文关注一个影响生产力的特定问题，但常常被忽略：你的数据库。你可能会惊讶地发现，当你的数据库及其相关流程阻碍开发者专注于真正重要的工作时，它对生产力的负面影响有多大。
你的数据库可能是问题所在
如果你观察大多数使开发者效率下降的原因，它们通常与应用数据库息息相关。你的团队只想快速完成代码交付，但这大部分需要与数据库交互。正是这种交互显著拖慢了团队的节奏。
与 DBA 团队的衔接问题
在足够大的组织中，独立的 DBA 团队管理数据库，负责审查并调整开发者提出的所有数据库变更。这种责任划分在一定规模下很合理——数据库的复杂性已经超出了单一团队的掌握。但这种模式会完全拖慢你开发特性时的节奏。49% 的组织表示其数据库审查和批准周期过长。
“在规划大规模扩展并快速迭代我们的特性时，PlanetScale 提供了世界级的运营能力、可扩展的平台，以及业务所需的灵活性。”
数据库变更的管理和部署是应用发布流程中最慢、风险最大的部分，原因在于这些变更大多是由 DBA 手动执行。从创建到审查，数据库变更流程耗费了大量时间，成为发布周期中的主要瓶颈。
更重要的是，**57% 的代码修改都需要数据库变更的支持**。如果一个 DBA 团队需要数周时间来批准和调整你的代码，这将显著降低开发者的生产力。
架构更改带来的顾虑
对于没有专门 DBA 团队的小型组织，问题却恰恰相反：开发者非常清楚数据库的敏感性，因此对于进行任何更改过于谨慎。48% 的组织表示其数据库变更流程有多处失败点。
你的开发者可能之前遭遇过停机或数据丢失，这促使他们对于数据库更改更加谨慎。然而，这种额外的谨慎显著拖慢了代码交付的速度。
持续监控与优化
高效的组织会在测试阶段内建性能和可扩展性检查，但未来是无法预测的。团队可能发布了一个快速加载的新特性，但随着底层表的增长和复杂化，性能逐渐下降。当应用变慢、用户开始抱怨时，开发者不得不投入时间重写查询、重构程序代码、修改架构甚至增加缓存（好运）。无论采用什么方法，团队都将花时间处理这些任务，而不是专注于新特性开发。
过去十年间，软件构建、测试和部署的方式发生了巨大变化，但与数据库的交互方式却几乎保持原样。
如果数据库能让你更高效会怎样？
自软件工程诞生以来，数据库就一直被排除在 DevOps 范畴之外。我们的应用代码受到严格的版本控制、审查、测试和部署，而数据库架构变更却依然是手动进行，并寄希望于“试试会不会成功”。 解决方案是将数据库引入 DevOps 工作流，并创建一个专门的变更管理流程。
下面是传统方式中的数据库变更工作流：
混乱且缓慢的传统工作流
为了进行架构变更，团队通常需要围绕构建新特性展开工作。大多数有意义的新特性都会涉及数据库变更。如果有 DBA 团队，变更请求会发送给他们进入审查流程。如果没有 DBA 团队，则开发者会在谨慎测试后尝试修改。如果一切顺利，那很好；否则问题会循环出现。
在整个过程期间，数据库本身几乎像一个无辜的旁观者。由于过去 20 年数据库基本保持不变，我们不得不围绕它构建这些笨重的变更流程，而软件开发和部署已经取得了巨大进步。
将数据库引入 DevOps 循环
你需要的数据库应该能够简化变更管理，将其像注释和点击一样简单地融入 DevOps 循环。PlanetScale 的一个核心理念是弥补数据库技术与过去 10 年软件交付方式变革之间的缺口。是时候改变了。
下面是几个 PlanetScale 的旗舰功能，能够释放开发者生产力：
如果你的数据库有分支呢？
创建新特性时的第一步通常是 git checkout -b "new-branch-name"——分支是现代软件开发的重要部分。PlanetScale 将这种功能扩展到了数据库中，让你可以创建独立、可合并的数据分支。
分支功能（Branches）
分支解决了架构更改的各种不确定性。当你创建一个分支时，会初始化一个隔离的数据库实例（开发环境下仅有架构），你可以在其中进行和测试更改。当你准备好时，只需像代码一样将其合并到主分支。
部署请求与数据库 CI/CD
当数据库在 DevOps 循环之外时，数据库变更通常是静态或非协作地完成和撤销的。PlanetScale 的 部署请求（Deploy Requests） 功能通过为团队提供一个单一视图，展示提议的变更及其影响，将数据库引入工作循环。
架构差异（Schema Diff）
部署请求可让管理员审查其对表的影响，并将请求合并到生产环境（所有操作都会存储在历史记录中）——类似在 GitHub 上的 Pull Request。这使得数据库变更具备内置审查流程。
轻松回滚架构变更
在理想世界中，开发环境会精确镜像生产环境，经过测试的架构变更每次都会顺利工作。但实际上，无论数据库如何顺利处理变更，偶尔还是需要回滚。这时 PlanetScale 提供了一个极为简单的解决方案：你可以通过点击按钮轻松撤销架构更改，无需停机或数据丢失。
Insights 和自动监控
使用分支和部署请求后，数据库变更可以无缝进入生产环境。下一步是监控这些变更，确保查询的性能表现符合预期。PlanetScale 的 Insights 功能为查询性能提供了细致入微的视图，并被原生内置到数据库中。
查询性能图表
你可以查看读取的行数、查询延迟、查询运行次数等指标。通过一个单一视图快速分析最近查询的性能表现及错误，让开发者能够快速调整，保持用户满意。
不妨听听用户的反馈
我们创建 PlanetScale 的初衷是因为对数据库成为客户特性开发瓶颈感到不满。从初创公司到财富 500 强，全球的开发团队都在使用 PlanetScale 的功能（如分支、部署请求 、和 Insights）来提升开发者生产力并加速产品交付。
“在快速迭代我们的特性时，同时规划大规模扩展是一项挑战所在。PlanetScale 提供了世界级的运营能力、可扩展平台和业务所需的灵活性。”
“我们以前每晚都得检查 AWS 控制台，现在已经完全不用担心 PlanetScale。我们不想成为 DevOps 的专家，也不需要负责数据库 DevOps 工作。我们只想专注于让我们的产品更好。”
“有 Insights 捕捉 100% 的查询，解决了一直以来无法满足的需求。你可以获得完整的性能图景。”
关注公众号：程序新视界，一个让你软实力、硬技术同步提升的平台
除非注明，否则均为程序新视界原创文章，转载必须以链接形式标明本文链接
