源代码管理中的存储过程 - 自动构建/部署过程

Question

我的公司提供了一个大型的面向.NET服务的解决方案。服务层与由数百个表和存储过程组成的T-SQL后端进行交互。我们的C＃代码是版本控制（SVN），但我们的存储过程和模式不是。

权宜之计上层管理的多的游说后，我被允许阅读我们的（不存在）的构建/部署过程实现以下目标：

1. 广场架构和源代码控制下的存储过程。
2. 自动构建/部署过程。

我想每个接受答案的战略继续在this post但还有其他问题：

1. 我想用哈德森作为我的生成服务器。这是C＃/ SQL解决方案的合理选择吗？我应该探索哪些更好的选择？

2. 假设我有所有的触发器，存储，程序，模式等等源代码控制下，并且他们照本宣科单个文件，我怎么生成构建脚本，将考虑到帐户之间的依赖关系/引用这些项目？ （SQL Server会自动执行此操作，但会生成一个巨大脚本）

3. 在客户端执行更新的工作流程是什么样子的？即我必须保留现有的表格数据。如何回滚模式更改？

4. 我是唯一的程序员。其他几个伪技术人员喜欢直接在SQL Management Studio中进行更改。期待别人遵守这个解决方案是否现实？我该如何执行？

非常感谢您的帮助。

编辑：

不幸的是，我们将不能够使用TFS。不过，我们的Visual Studio 2008/2010提供了可用的数据库项目组件，因此看起来我必须将基于脚本的解决方案整合在一起。任何建议/更新将不胜感激。

Answer 1

T-SQL部署Microsoft栈上的规范示例是Visual Studio数据库项目部署过程。在这个过程中，你的数据库模式，过程，权限分配和几乎所有的东西都被存储为一个VSDB项目，这意味着它们被存储为SQL定义文件，并在源代码控制下检查（SVN是好的）。 'build'过程提供了一个.dbschema文件，该文件是一个包含整个VSDB项目综合的文件（是一个荣耀的XML文件）。然后将.dbschema文件发送到部署服务器（开发服务器，QA验证服务器，甚至是产品服务器）和“已部署”。通过vsdbcmd工具完成部署，该工具将在部署服务器和.dbschema文件之间运行复杂的差异，并根据需要使用CREATE/ALTER/DROP语句将服务器与.dbschema文件的内容“对齐”。存在于目标数据库/服务器中。

一个连续集成的过程将开始夜间构建，将.dbschema和其他可交付物放在测试SQL服务器上，部署。dbschema，然后运行构建验证测试，并且如果最后所有内容都会丢失完整的构建和QA验证的可交付内容，则每日“下降”。完全集成到部署到生产的所有方式都是可能的，但通常可避免由于中央，生产和服务器意外停机的风险。然而，完全集成和部署到生产环境通常是多服务器环境的常态，“生产”意味着数百/数千个已部署的服务器。

现在你说你想要使用Hudson进行部署，除非你必须重新创建上述步骤中描述的所有东西，蚂蚁将构建步骤，并且您将花费未来10年时间重新创建VS DB项目概念，如.dbschema文件和像vsdbcmd这样的工具。我不是那种能够投资购买基于VSDB和TFS的构建服务器许可证的人，但我说我并不知道OSS中提供的端到端解决方案。在VS 2010中，我相信数据库项目是标准版。在VS 2008中，你需要高端许可证。

随着用户做的改变骑鸟枪从SSMS的：你可以阻止他们使用DDL triggers，则可以使用Event Notifications跟踪他们，或者你可以把它们用C2 compliant audit全面审计。