暂存数据库困境
假设有 3 个用于
- Production
- Staging
- Dev
的数据库据我所知，Staging 数据库需要与 Production 数据库同步 但是，
当我们开发时，我们可以使用 Dev 数据库做任何我们想做的事情并更改架构。 现在鸡和鸡来了。 鸡蛋问题。
要在 Staging 中进行测试，需要根据 Dev 数据库中所做的更改来更改 Staging 数据库架构。 但临时数据库需要与生产同步。
你们如何解决这个问题？
Suppose that there are 3 databases for
- Production
- Staging
- Dev
As far as I know, Staging database need to be in sync with Production database
But,
When we are developing, we can do whatever we want with Dev database and change schema.
Now here comes the Chicken & Egg problem.
To test in Staging, Staging database schema need to be changed according to changes made in Dev database. But the Staging database need to be in sync with Production.
How do you guys get around this problem?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
您需要将所有更改写入开发数据库作为按特定顺序运行的 SQL 迁移脚本。 不要更改数据库结构，除非是在脚本中。 不要更新、插入或删除任何行，除非它位于脚本中。
理想情况下，有一种方法可以跟踪针对您找到的任何版本的数据库运行了哪些脚本。
然后您可以按如下方式更新阶段。
一旦一切正常...
You need to write all of you changes to the dev database as SQL migration scripts that get run in a certain order. Do not change the database structure unless it is in a script. Do not update, insert or delete any rows unless it is in a script.
Ideally have a way to track which scripts have been run against any version of the database you find.
Then you can update stage as follows.
Once everything works ...
暂存需要与生产同步，仅在您部署新更改时为止。
或者创建一个名为“测试”的第四个环境，在其中验证新的升级。 我们将其称为 UAT/Test，它通常是临时服务器上的第二个数据库。
确切的方法将取决于您如何保持同步。 你真的在使用复制吗？ 或者只是将 Prod 备份/恢复到 Stage？
Staging needs to be in sync with production, only up to the point where you are deploying new changes.
That or make a 4th environment called Test where new upgrades are validated. We call ours UAT/Test, and it is typically a second database on the Staging server.
Exact methodology will depend on how you are keeping things in sync. Are you actually using replication? Or just a backup/restore of Prod to Stage?
“临时数据库需要与生产同步”不正确。
生产模式（“设计”）与暂存模式同步。 舞台表演在前，制作在后。
有时，人们将生产数据移至暂存阶段以帮助测试，但这可能很危险，具体取决于您所在的行业。
舞台表演是“纯粹的”。
生产是通过将真实数据放入纯暂存模式中从暂存构建的。
有些人所做的是拥有两个数据库。
今天#1 正在制作，#2 正在上演。
明天我们计划对架构进行更改。 我们将#2 升级为新设计。 然后我们将数据从#1 移动到#2。
然后，当我们完成数据移动后，我们切换应用程序软件以使用#2 作为生产。
我们将#2 作为生产运行，直到进行下一次更改为止。
"Staging database need to be in sync with Production " Not true.
Production Schema ("design") is in sync with Staging Schema. Staging comes first, production follows.
Sometimes people move production data down to staging to help test, but that can be dangerous, depending on your industry.
Staging is "Pure".
Production is built from staging by putting real data into the pure staging schema.
What some people do is have two databases.
Today #1 is production, #2 is staging.
Tomorrow we plan to do a change to the schema. We upgrade #2 to the new design. Then we move data from #1 to #2.
Then, when we're done moving data, we switch application software to use #2 as production.
We run with #2 as production until it's time for the next change.
我们仅使用临时数据库来测试我们的部署机制。 它与生产相匹配。
我们在开发过程中进行更改并定期将其部署到质量检查。 一旦我们准备好投入生产，我们就会将所有更改聚合到一个发布包中。 该发布包首先在登台进行测试，然后如果没有部署问题，则将其推送到生产环境。
We use our staging database only to test our deployment mechanism. It matches production.
We create our changes in development and periodically deploy them to QA. Once we are ready to go to production, we aggregate all changes into one release package. That release package is first tested on staging, and then if there are no deployment problems it is pushed to production.
如果您有能力添加测试环境，您可能需要考虑这一点。
否则，您基本上需要在开发环境中进行测试。 直到您对该版本有足够的信心，可以在暂存环境中进行架构更改。 经常进行备份并制定良好的回滚程序，以便在将架构更改推送到暂存时出现问题时，您可以随时回滚。
另外，比较数据库架构的一个好工具是 SqlCompare。 在推送架构更改之前，您应该始终使用类似的内容。
If you can afford to add a testing env, you may want to consider that.
Otherwise you basically need to do your testing in your dev env. up to a point where you're confident enough with the release that you can make the schema changes in your staging env. Make frequent back-ups and have a good roll-back procedure so that if something goes wrong when you push the schema changes to staging you can always roll-back.
Also, a good tool for comparing database schema is SqlCompare. You should use something like this always before you push the schema changes.