Visual Studio 2010数据库项目部署策略
我刚刚阅读了 VS 2010 数据库项目指导文档（指导文档链接），但我仍然一无所知更明智地了解持续集成数据库构建和数据库单元测试的明智策略。
目前，我们的数据库项目与我们的应用程序位于同一解决方案中，并在签入时构建整个解决方案，每次构建都部署数据库是否实用？
我们是否应该将数据库项目分离到另一个解决方案，然后减少它们的构建频率，以便在构建上部署会更明智？
我们是否应该忘记自动部署所有内容并使其成为手动步骤？
如何为数据库单元测试项目部署数据库？
指导文件中有很多信息，但没有明确的答案。
谢谢 本
I've just read the VS 2010 Database Project Guidance document (link to guidance document) and I'm still none the wiser about what's a sensible strategy for Continuous Integration DB builds and Unit Testing the DB.
We currently have our DB project in the same solution as our application and build the whole solution on check-in, is deploying the DB with every build practical?
Should we separate the DB projects to another solution and then they'd get built less often so deploying on build would be more sensible?
Should we forget about automatically deploying all together and just make that a manual step?
How do you deploy databases for Database Unit Test projects?
There's a lot of information in the guidance document but no definitive answers.
Thanks
Ben
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
这取决于你的目标是什么。您考虑在每个构建中部署到什么环境？
部署的频率和地点通常由您的 QA 和/或发布流程决定。我假设您不想在每次签入时自动部署到生产数据库，很可能您需要首先进行 QA 流程。
因此，我会查看您拥有哪些环境、它们的用途是什么以及您希望它们多久更新一次。每晚更新 QA 环境是很常见的，但每次签入时更新都会扰乱 QA 活动。
有些人有一个在每个构建上部署的环境，并且针对它运行自动化测试，如果您有这个环境，那么在每个构建上部署都是有意义的。
您可以构建数据库项目而无需部署它们，当涉及 Visual Studio 中的数据库项目时，构建和部署是不同的概念。
It depends what your goals are. What environment(s) are you considering deploying to on every build?
How often, and where, you deploy to is usually determined by your QA and/or release processes. I'm assuming you don't want to auto-deploy to the production database on every check-in, chances are you have a QA process that needs to happen first.
So I'd be looking at what environments do you have, what are they used for, and how often would you like them to be updated. It is pretty common to have a QA environment that is updated nightly, but updating it on every checkin would disrupt QA activities.
Some people have an environment that is deployed to on every build and automated tests are run against it, if you have this then deploying there every build would make sense.
You can build DB projects without having to deploy them, the build and deploy are separate concepts when it comes to DB projects in Visual Studio.