我遇到了一个问题，我可以利用一些反馈以尽可能好的方式解决它。
这个问题围绕着源代码管理->自动化构建->部署展开。基本上是ALM（应用程序生命周期管理）。
我们有一个产品——一个带有MS SQL数据库的ASP.NET Web应用程序。该产品在我们的生产环境中的多个虚拟机上运行在数百个具有相关数据库的网站上。目前，web应用程序和数据库正在装有IIS 7和SQL database Server 2008 R2的服务器上运行。该产品本身在Team Foundation 2012中受源代码管理。
多年来，该产品的新版本每年发布一到两次，持续多年。现在我们将集中精力更频繁地发布，因此我们需要为产品的ALM制定一个策略。
现在的部署策略：
在两个版本之间的开发阶段，SQL更新脚本是手动创建的——每次更改数据库时，都会更新一个脚本。当应用程序准备好部署时，它将在开发人员机器上进行编译。将使用所有更改的数据库备份到.BAK文件中。web应用程序、.BAK文件和更新SQL脚本将被打包（.zip）并上传到生产环境中，以便进行部署。
更新现有运行的产品：
- 将web应用程序复制/粘贴到目标网站物理文件夹中
- 更新web.config文件-连接字符串和应用程序
- 变量。通过SQL Management Studio运行更新脚本
这将为每一位客户进行数百次。
这是一项非常乏味且容易出错的任务，我一点也不喜欢！
我想做的是
- 源代码管理将数据库作为Team Foundation中的数据库项目
- 使用Team Foundation 2012自动生成web应用程序生成服务器
- 将生成服务器的输出部署到的多个网站生产环境以及自动生成的SQL针对SQL Server运行的更新脚本
我一直在谷歌上搜索——只找到关于构建、部署、自动SQL更新脚本等的点点滴滴。
我认为部分正确的方向是源代码管理数据库并使用TFSBuildServer。我对如何使用TFSBuild服务器的输出以简单可控的方式进行部署感到非常困惑。
理想情况下，我希望TFS Build服务器创建一个包含最新版本的Web应用程序、最新版本数据库、部署后脚本的包，其中包括从以前的版本到当前版本的自动生成的SQL Update脚本。这可以包含在例如nuget包中。然后，我希望能够创建一个额外的web应用程序来管理部署——目标、版本、iis网站、sql server、web.config连接字符串等。
有人对如何实现这一目标有什么建议吗？你是怎么做到的
您可以使用发布管理工具来完成此操作，而无需创建额外的web应用程序。
一个这样的例子是来自RedGate的Deployment Manager。（免责声明：我在那里工作。）它内置了ASP.NET应用程序和SQL Server数据库的部署操作。命令行工具RgPublish.exe可用于创建web应用程序包，如您在TFS Build中所述。使用sqlCI.exe命令行和关联的NANT/MSBuild脚本也可以对数据库执行同样的操作。
然后可以将相同的包部署到您的每台服务器上。不过，您可能会遇到100个网站的可扩展性问题。
数据库部署的工作方式是自动生成升级脚本，不过您可以在首次构建包时更改行为以将升级脚本放入包中。这些方法分别称为"动态"one_answers"静态"升级方法。