随笔分类 - TFS
摘要：代码在真正进入代码仓库之前, 应该有机会通过一种和已有代码合并的集成性生成验证过程, 如果验证过程失败则拒绝签入. 有些源代码控制和生成平台提供了这样的选择. 但是TFS没有这样的功能. TFS的服务器生成过程, 总是以当前代码仓库中的代码为目标的. 值得注意的是, TFS在创建新的生成类型定义的向导中向我们提供触发器(Trigger)选择时, 给我们提供了一种"代码签入时引发生成"的选项. 这个选项所谓的生成过程, 是在签入后而不是签入前!
面对这样的功能性缺失, 而我们又有迫切的验证修改正确性的需求, 我们该怎么办呢?
答案就是Desktop Build.
阅读全文
摘要：重写团队基础生成流程, 是团队基础最富于弹性和扩展能力的地方, 也是实践最多优劣各异的地方. 这是MSBuild引擎的优秀能力: 给MSBuild引擎提供任意一个格式正确的生成脚本, MSBuild引擎都能搞解析生成脚本并形成可以顺序(或并行)执行的执行顺序流. 所以我们现在回过头来看, Team Build是什么? 我们试着从本质上归结一下:
"在MSBuild引擎驱动下的, 以团队基础框架提供的包含一系列生成目标(Target)的默认生成脚本文件 - Microsoft.TeamFoundation.Build.targets - 为基础的, 可以被用户自定义生成脚本文件 - tfsbuild.proj - 所覆盖从而形成一条确定的可执行的生成流程."
阅读全文
摘要：微软真的偷懒了 - 在上一节讨论中已经提到, 我们希望每次生成所使用的生成号(BuildNumber)和附加在程序集上的版本标记一致.这样才能在程序集版本信息和特定的生成过程之间建立起联系. 本质上是管理的需求. 但是默认的生成号产生机制给我们带来了比较大的麻烦. 因为程序集版本号的格式, 一般是这样的: xx.xx.xxxxxx.xx, 即主版本号(Major Version No.), 次版本号(Minor Version No.), 生成号(Build No.), 修订号(Revision No.)
这是符合长期以来程序集的版本号命名格式习惯的...
阅读全文
摘要：TFS 2008作为一个成熟团队日常管理应用平台, 现在已经被很多团队所采用. 与之相关的自动化构建流程, 也日益成熟. 但是, 笔者还是会经常看到一些比较拙劣的实现, 或者"拆东墙补西墙"的做法. 这样做或者直接影响到TFS的使用者, 或者解决了眼下问题却在不经意间引入了另外的问题. 这个系列的文章, 希望着眼于实践而不是技术本身, 讨论在TFS 2008的过程中的最佳方法和方案, 从自动化构建的需求的方方面面考虑, 总结出一条比较平衡和成熟的道路, 使自动化构建流程更加完整高效.
阅读全文
摘要：本文关注自动化构建实践中的第一个问题, 程序集的版本信息标记. 我们是否应该在自动化构建过程中更新程序集版本信息? 这样做有什么好处或者弱点? 有没有比较好的做法来解决这一问题? 相信在本文中给出了一个解答.
阅读全文
