我的公司提供大型 .NET 面向服务的解决方案。服务层与由数百个表和存储过程组成的 T-SQL 后端交互。我们的 C# 代码在版本控制 (SVN) 中，但我们的存储过程和模式不是。
经过权宜之计的高层管理人员的多次游说，我被允许审查我们的(不存在的)构建/部署过程以实现以下目标:
- 将架构和存储过程置于源代码控制之下。
- 自动化构建/部署过程。
我想按照 this post 中已接受答案的策略进行操作但还有其他问题:
我想使用 Hudson 作为我的构建服务器。这是 C#/SQL 解决方案的合理选择吗？我应该探索哪些更好的替代方案？
假设我有所有触发器、存储过程、模式等...都在源代码控制下，并且它们被编写到单独的文件中，我如何生成一个构建脚本来考虑依赖项/引用在这些项目之间？ (SQL Server 会自动执行此操作，但会生成一个巨大的脚本)
在客户端执行更新的工作流程是什么样的？即我必须保留现有的表数据。如何回滚架构更改？
我是唯一的程序员。其他几个伪技术人员喜欢直接在 SQL Management Studio 中进行更改。期望其他人遵守这个解决方案是否现实——我该如何强制执行？
预先感谢您的帮助。
编辑:
很遗憾，我们将无法使用 TFS。不过，我们确实有 Visual Studio 2008/2010 和可用的数据库项目组件，所以看起来我必须拼凑出一个基于脚本的解决方案。任何建议/更新表示赞赏..
最佳答案
Microsoft 堆栈中用于 T-SQL 部署的典型示例是 Visual Studio 数据库项目部署过程。在此过程中，您的数据库架构、过程、权限分配和几乎所有其他内容都存储为 VSDB 项目的一部分，这意味着它们存储为 SQL 定义文件，并在源代码控制下进行检查(SVN 很好)。 “构建”过程提供一个 .dbschema 文件，该文件包含整个 VSDB 项目的综合(是一个美化的 XML 文件)。然后将 .dbschema 文件传送到部署服务器(开发服务器、QA 验证服务器，甚至生产服务器)并“部署”。部署是通过 vsdbcmd 完成的该工具将在部署服务器和 .dbschema 文件之间运行复杂的差异，并根据目标数据库中存在的内容，酌情使用 CREATE/ALTER/DROP 语句将服务器与 .dbschema 文件的内容“对齐”/服务器。
一个连续集成的过程将开始每晚构建，将 .dbschema 与测试 SQL 服务器上的其他可交付成果一起删除，部署 .dbschema，然后运行构建验证测试，如果一切顺利，最终将删除一个完整的构建和 QA 验证的可交付成果，即每日“下降”。完全集成一直到部署到生产中是可能的，但通常由于中央生产服务器意外停机的风险而避免。然而，完全集成和部署到生产中通常是多服务器环境的规范，其中“生产”意味着成百上千个已部署的服务器。
现在你说你想使用 Hudson 进行部署，这很好，除了你必须重新创建我在上面的步骤中描述的所有内容作为 Ants 构建步骤，你将在接下来的 10 年里重新发明 VS DB 项目概念，如 .dbschema 文件和工具，如 vsdbcmd。我不是那个可以打电话投资购买基于 VSDB 和 TFS 的构建服务器许可证的人，但我是说我不知道 OSS 中可用的端到端解决方案。我相信，对于 VS 2010，数据库项目是标准版。使用 VS 2008，您需要高端许可证。
当用户使用 SSMS 进行更改时:您可以使用 DDL triggers 来阻止他们，您可以使用 Event Notifications 跟踪它们，或者您可以使用 C2 compliant audit 全面审核它们.
关于c# - 源代码管理中的存储过程 - 自动化构建/部署过程，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/2909198/