在 VSTS 中的现有数据库上手动将数据库部署到 SSDT

Question

我们有一个实时数据库项目，我们目前仅通过手动部署对其进行更新。然而，作为我们流程改进计划的一部分，我们建议切换到 SSDT 以使我们能够改进并将一些自动化引入我们的部署流程。

为了促进概念验证，我们提供了一个测试环境，我们可以在其中实施和测试 SSDT 部署到现有 Live 数据库的克隆或类似表示，该数据库当前在 Git 存储库中维护VSTS。

不过，我确实对此有一些担忧和疑问。

1. 在不影响 Live 环境的情况下，为我们的 SSDT 部署克隆或重新创建 Live 数据库到测试环境的推荐方法是什么？
2. 将 Live 数据库导入我们的 SSDT 项目，然后发布到测试环境会对 Live 环境产生任何不利影响吗？导入后两个数据库之间是否会出现任何不一致？
3. 如果我们的概念证明成功，我们是否需要将所有数据库资产迁移到新的 SSDT 项目，或者 SSDT 项目能否与我们现有的 Live 数据库项目并行运行？如何？
4. 任何切换或迁移到 SSDT 是否会导致我们的项目团队停机或中断？
5. 如果不需要将我们现有的数据库资产迁移到新的 SSDT 项目，我们是否可以将 SSDT 功能集成到现有项目中。

Answer 1

让我们来看看你所有的问题：

1. 克隆是什么意思？复制结构还是使用数据？无论如何，您都需要导入架构。创建新项目并通过右键单击该项目来导入架构。如果您还需要数据，那么最好的方法是备份/恢复。
2. SSDT 自然不适用于数据。它只有 DDL。因此，当您同步结构时，性能效果取决于所做的更改。重新创建索引可能需要很长时间，但是创建表不会占用太多资源。再说一次，如果您谈论的是备份，那么您需要衡量它们对您的影响程度。
3. SSDT 是您存储和开发代码的方式。去不去都取决于你。我认为 SSDT 是 SQL Server 开发的最佳工具，但正确设置它可能会成为一项挑战。
4. 正如我已经说过的，这完全取决于更改。有些更改不会停机，而有些更改可能非常复杂。 SSDT 只会生成 SQL 脚本，它是由 SSDT 手动运行还是自动运行没有区别。
5. 不太清楚迁移是什么意思。 SSDT 是您存储和开发代码的方式。任何 SQL Server 数据库都可以放入 SSDT（对于某些现有数据库，您需要付出一些努力才能进入 SSDT，但这确实是可能的）