尝试让我的生活更轻松，目前我们有4名开发人员在Visual Studio 2012中工作，我们正在使用TFS 2012进行源代码管理。我们所处理的项目是一个多租户Web应用程序（具有多个dbs的单一源目录），它是legacy，asp和vb6 com组件的混合，再加上新的C＃代码。我们使用TFS进行源代码控制以及管理用户故事和错误。由于我们的站点工作方式，它不能仅在服务器上本地运行或调试。 源代码管理当前设置为每个开发人员一个单独的分支，其工作目录映射到开发服务器上的共享网络路径，该服务器在IIS中具有指向它的网站。 Dev01-Dev05等开发人员在他们的分支机构中使用他们的开发网站对项目进行测试，然后检查他们自己的分支的变化并将它们合并到主干中。 trunk的工作空间映射到主dev网站，以便开发人员可以针对其他客户的开发域测试他们的更改，以根据连接到的特定dbs来测试功能的自定义和差异。
很长的解释，但基本上每个开发人员都有一个分支和一个站点，然后将它们合并到拥有自己站点的主干中。
为了部署我们的登台服务器：
我尝试过使用TFS自动构建的东西，从来没有真正得到它来正确构建网站。使用Cruise Control也很成功。使用臭鼬工程项目来实现这一目标非常耗时且充其量不可靠。
我的完美情景是：
我怎样才能到达这里，以便我不花费数小时准备和部署发布到分段和最终生产？对潜在的解决方案非常开放，难以改变的事情将是我们正在使用的源代码控制，无法真正切换到颠覆或其他东西，所以我们非常坚持使用TFS。
由于
答案 0 :(得分：2)
回来并开始尝试让TFS构建/发布我的网络解决方案。我能够成功完成构建。添加msbuild参数/ p：DeployOnBuild = True并将msbuild平台设置为x86似乎可以解决这个问题。 然后我找到了https://github.com/red-gate/deployment-manager-tfs，它为您提供了一个构建过程模板，用于使用redgate工具进行打包和部署。在玩了一下后，我终于得到它来创建，打包和部署我的构建到我们的临时环境。
接下来将修改模板以运行一些自定义脚本以仅收集要部署的正确项目，部署所有sql文件，然后在完成后将工作项设置为适当的状态。
答案 1 :(得分：1)
您的流程的详细说明。谢谢分享！
我相信您可以将TFS设置为在单个分支上拥有gated check-in，如果您可以在trunk上设置，则可确保成功构建合并。这可能会触发msbuild，如果你可以使用它或自定义构建作业。
如果能够正常工作，那么您就可以将该中继代码用作要发送到Deployment Manager的工件。这样可以避免必须通过TFS更改集来组装文件以进行部署，因为您可以确信主干始终可以构建。
您是否使用Deployment Manager从源代码管理和应用程序部署数据库？
这可能是进一步实现流程自动化的一种方式。 SQL Source Control和SQL CI允许您控制数据库的结构，在每次签入时使数据库保持最新，并运行数据库单元测试。它们还为Deployment Manager生成数据库包，因此您可以部署包含应用程序和数据库的发行版。
如果您希望向我发送您在步骤4中使用的命令，以使用Deployment Manager部署该版本，我可以提供帮助。我使用的命令是：
DeploymentManager.exe --create-release --server=http://localhost:81 --project="Project Name" --apiKey=XXXXXXXXXXX--version=1.1
DeploymentManager.exe --deploy-release --server=http://localhost:81 --project="Project Name" --apiKey=XXXXXXXXXXX--version=1.1 --deployto=CI-Environment-Name
这将使用该项目的最新可用包创建发行版本1.1。您可以选择指定使用
创建发布时要使用的包--packageversion=<package name>=<version>
--packageversion="application=1.5