03 2010 档案
摘要：重写团队基础生成流程, 是团队基础最富于弹性和扩展能力的地方, 也是实践最多优劣各异的地方. 这是MSBuild引擎的优秀能力: 给MSBuild引擎提供任意一个格式正确的生成脚本, MSBuild引擎都能搞解析生成脚本并形成可以顺序(或并行)执行的执行顺序流. 所以我们现在回过头来看, Team Build是什么? 我们试着从本质上归结一下:
"在MSBuild引擎驱动下的, 以团队基础框架提供的包含一系列生成目标(Target)的默认生成脚本文件 - Microsoft.TeamFoundation.Build.targets - 为基础的, 可以被用户自定义生成脚本文件 - tfsbuild.proj - 所覆盖从而形成一条确定的可执行的生成流程."
阅读全文
摘要：想做你的code - 视频 - 优酷视频 - 在线观看 微软推销VS换了角度, 开始从程序员入手了, 程序员兄弟们看了应该会有点感觉; 程序员的自我关怀, 自尊和被认同; 你永远只在自己的船上 - <浮沉> 程序员和销售以及老板 - 生产力和价值的倒挂 软件行业的特殊特点 - 软件的独特商品本质; 太文艺了!
阅读全文
摘要：微软真的偷懒了 - 在上一节讨论中已经提到, 我们希望每次生成所使用的生成号(BuildNumber)和附加在程序集上的版本标记一致.这样才能在程序集版本信息和特定的生成过程之间建立起联系. 本质上是管理的需求. 但是默认的生成号产生机制给我们带来了比较大的麻烦. 因为程序集版本号的格式, 一般是这样的: xx.xx.xxxxxx.xx, 即主版本号(Major Version No.), 次版本号(Minor Version No.), 生成号(Build No.), 修订号(Revision No.)
这是符合长期以来程序集的版本号命名格式习惯的...
阅读全文
摘要：TFS 2008作为一个成熟团队日常管理应用平台, 现在已经被很多团队所采用. 与之相关的自动化构建流程, 也日益成熟. 但是, 笔者还是会经常看到一些比较拙劣的实现, 或者"拆东墙补西墙"的做法. 这样做或者直接影响到TFS的使用者, 或者解决了眼下问题却在不经意间引入了另外的问题. 这个系列的文章, 希望着眼于实践而不是技术本身, 讨论在TFS 2008的过程中的最佳方法和方案, 从自动化构建的需求的方方面面考虑, 总结出一条比较平衡和成熟的道路, 使自动化构建流程更加完整高效.
阅读全文
摘要：本文关注自动化构建实践中的第一个问题, 程序集的版本信息标记. 我们是否应该在自动化构建过程中更新程序集版本信息? 这样做有什么好处或者弱点? 有没有比较好的做法来解决这一问题? 相信在本文中给出了一个解答.
阅读全文
