在Vercel, netflix, Linc等现代云部署服务中，在每次提交pull请求时部署web应用程序已经很流行了。这对前端代码很有意义。
它也变得流行起来，然而，像NextJS这样的框架，将API部署在与前端代码相同的代码库和基础设施中。但是api通常需要数据库才能运行，而数据库通常会随着迁移而更改模式。对我来说，这意味着如果分支上的数据模型发生了变化，那么部署在前端/API单体中的预览通常会失败。
其他人是如何处理这个"预览部署"的?开发模式，何时涉及数据库?是否有一种优雅的方法可以在每个预览部署中启动单独的数据库实例，使其与每个分支定义的模式/迁移相匹配，并与这些非常分布式的、通常无服务器的托管提供商一起工作?
一些最初的想法
- 是否有一种快速而廉价的方法来从部署上的模板启动DB(基于项目的
main分支)，在其上运行特定分支的迁移，并有Vercel预览部署以某种方式发现新的DB实例?如果这样的数据库有很多数据，它还能保持敏捷吗?也许用Docker镜像? - 也许签入的
sqlite数据库可以很容易地支持预览部署，只要它假设预览部署没有太多的并行访问?但是，除非您使用sqlite作为您的prod DB，否则它会在预览和生产环境之间产生显着差异 - 或者将数据模型耦合到预览部署完全是一个坏主意，数据访问应该与这种前端代码分开。
很想听听别人都做了些什么。
我可以想到(和使用)的几种方法
环境变量例如，在vercel中，您可以配置单独的生产、登台和开发环境变量。
您可以将暂存database_uri环境变量设置为内存中的sqlite3数据库(在vercel中没有对无服务器的文件系统访问)，用于任何手动测试/演示，并在生产环境中使用不同的变量
另一种方法是使用main或master作为开发分支，并有一个单独的production分支。将vercel(或您的平台)配置为仅在推送到该生产分支时进行构建。
虽然你实际上不会推送到这个分支，但你会从main(或任何其他默认)分支中拉出并合并到prod分支中。