我正在努力找出如何在本地PC上正确测试东西，然后将其转移到生产中。下面是我的情况:
我有一个项目在NodeJS/typescript，我使用Prisma在它管理我的数据库。在我的服务器上，我只运行MySQL数据库，在我的PC上进行测试时，我总是使用SQLite。
但是现在我想使用Prisma Migrate(因为强烈建议在生产中这样做)，我不能，因为我在PC上使用不同的数据库，而在我的服务器上。现在我的问题来了，正确的方法是什么在开发过程中测试数据库吗?
我应该只是连接到我的服务器，使一个测试数据库吗?使用VS Code的SSH编码功能直接在服务器上编码并连接到数据库?在我的电脑上安装MySQL ?比如，正确的方法是什么?
始终使用相同品牌和相同版本您最终将部署到的开发和测试中的数据库。品牌之间存在兼容性差异，即在SQLite上工作的SQL查询不一定在MySQL上工作，反之亦然。甚至在不同的SQL产品之间，数据类型和模式定义也不尽相同。
如果你在开发和生产中使用不同的SQL数据库，你将浪费大量的时间，并增加你在生产中调试问题的白发，正如你坚持的那样，"它在我的机器上工作"。
这是可以避免的!
当我在本地计算机上开发时，我通常在笔记本电脑上的Docker容器中运行MySQL Server的实例。
我假设笔记本电脑上的任何测试数据都是临时的。我可以随时使用签入源代码控制库的脚本轻松地重新创建模式和数据，因此我不用担心丢失任何数据。事实上，我毫不犹豫地放下它，每周重新创作几次。
因此，如果我需要升级本地数据库版本以匹配生产上的升级，我只需删除Docker容器及其数据，拉出新的Docker映像版本，初始化新的数据目录，并重新加载我的测试数据。
每一步都是脚本化的，甚至包括Docker的pull。
对我的实践的警告是，如果您使用云数据库，例如Amazon Aurora，则不一定可以复制软件。没有办法在你的笔记本电脑上运行一个与Aurora兼容的实例(不要相信销售人员说的Aurora与MySQL完全兼容;这不是)。所以你可以在开发VPC中运行一个小的Aurora实例，并从你的应用程序开发环境连接到它。至少如果你的网络连接足够可靠的话。
顺便说一下，类似的规则适用于您在开发中使用的所有其他技术。Node.js、Prisma、其他NPM依赖、http和缓存服务器等的版本。甚至操作系统也可能是兼容性问题的根源，但您可能必须在虚拟机中进行开发，以使操作系统与生产环境完全匹配。
在过去的一份工作中，我确实帮助开发团队创造了我们所谓的"黄金形象"。它是一个预先配置的虚拟机，安装了我们所有的软件依赖项，我们将这个黄金映像用于开发人员沙盒虚拟机，以及我们启动生产Amazon EC2实例的AMI。因此，所有开发人员都可以保证拥有与生产环境完全匹配的测试环境。在那之后，如果他们有代码问题，他们可以在开发中修复它，并且在部署到生产环境后有更高的信心可以正常工作。