想知道推荐的过程,即在成功构建后检入项目或解决方案的输出。如何检查项目/解决方案(dll)的输出在TFS2010中发布成功构建
例如,Build涉及到一个公共库。发布更改我希望将其签入到已知位置,以便其他解决方案可以参考。
一些例子可能是
- 自定义工作流活动
- 调用TF exe文件直接
想知道推荐的过程,即在成功构建后检入项目或解决方案的输出。如何检查项目/解决方案(dll)的输出在TFS2010中发布成功构建
例如,Build涉及到一个公共库。发布更改我希望将其签入到已知位置,以便其他解决方案可以参考。
一些例子可能是
看看这个帖子从Ewald Hofman,it updates certain files and checks them in using a custom activity。你可以使用相同的过程。但是这涉及到定制构建过程模板并将定制构建活动部署到所有构建代理。
但您可能还想调查免费的AIT Dependency Manager,它可以从构建服务器下载最新的特定版本(可以过滤构建结果或质量)作为另一个构建(也包含在Visual Studio中)的参考。这比经常检查构建输出更灵活,并允许您的开发分支始终获取最新(不稳定)版本,但您的发布分支始终获得最新的经过良好测试和认可的版本。
谢谢jesse我真的绊倒了那个。我们有一种情况,我们正在使用TFS2010,但真正的TFS2008构建过程 – merbla 2012-02-17 07:08:11
如果您没有在msbuild中执行过多的自定义事情,那么将其升级到TFS 2010模板应该不会太难。否则,请尝试从2010工作流程中调用2008 proj文件,该文件通常工作得很好。 – jessehouwing 2012-02-17 19:23:55
我不会检查的输出。相反,我会把它转移到一个众所周知的位置,可能是文件共享。
默认情况下,文件共享存在.NET不受信任的常见问题。您可以通过运行CasPol来显式信任共享来解决此问题。请参阅:http://thebackroomtech.com/2009/04/01/using-caspolexe-to-grant-net-applications-rights-to-a-remote-network-share/ – jessehouwing 2012-02-16 12:24:12
我目前没有这样做,但计划调查NuGet作为此场景的解决方案。 MSDN有一些文章展示了如何将NuGet整合到您的项目中,并承载您自己的NuGet包的私人画廊。 MSDN有一个构建的例子,它编译你的通用代码,然后将它打包并更新到你的私人NuGet库中。然后在你的项目中,你会使用你想使用的公共库的NuGet包。
描述这主要MSDN文章: http://msdn.microsoft.com/en-us/magazine/hh781026.aspx
其他资源:
一个在现代CI-环境的目标是/应该是每个构建能随时重复。如果每个构建都检查某些内容,则会破坏目的。另请参阅此帖是否有帮助:http://stackoverflow.com/a/8578128/728929 – pantelif 2012-02-16 12:45:57