大型.NET项目的目录、编译和版本管理实践 三

日常工作

更新组件

每个程序员在开始新的工作前,都应该先更新最新的组件,如果更新所有的源代码其实是非常耗时的动作,所以我们会仅更新最新的成果(即当前产品单元下bin目录文件),以及你当前已经打开的项目源代码。如果通过“项目工具”添加一个现有项目到解决方案,也会询问是否获取最新版本。

由于之前做了大量的准备工作,所以更新非常容易,但我们仍然认为此动作太常用,所以在工具栏上包含了此按钮,他会通过TFS强制下载最新的bin目录文件。然后会将所有文件的只读属性去掉,为什么要这么做呢?不然你编译就无法覆盖这些只读文件了,这也是我为什么强调是“强制下载”的原因。

有些时候,服务器上发布的版本有些问题,所以你可能希望获得昨天的版本,TFS正好提供了这个特性,因此此按钮还允许你选择一个特定的版本。

image17

编译和调试

我们每天都需要做很多次的源代码修改,然后编译他,调试,最后成功后发布或者定期自动发布。

调试,或者说让程序跑起来(Run),你可能认为直接按F5不就结了(F5是VS调试的快捷键)。如果你是项目只有一个exe和一堆dll,那么可能的确是这样。但我们现在讨论的是大型项目,所以就稍微复杂点点了,比如平台组的程序员,他编译更新的只是部分组件,即其bin目录下也只是部分dll,要跑起来需要有完整的运行环境。再比如,平台的组件可能作为很多的产品底层,因此运行需要决定运行哪个产品,这就又需要“项目工具”了。

image14

第一个按钮是运行,第二个是编译,大家都知道的我就不罗嗦了。关键是第三个文本框,他可以录入一个路径,他就是你运行时目录。当编译时,工具先编译解决方案(跟你点击VS的Build效果一样),然后再执行一段自定义的MSBuild过程,他的任务是将编译更新的成果(例如dll)按照自定义的规则复制到运行目录下。这个自定义的MSBuild过程其实是解决方案相同目录下的一个UpdateRuntime.proj的文件,每个产品单元会手工编写这个文件完成这个任务。

这种方式有个小小的问题,如果你的bin目录下的文件和子目录太多太多,这个自定义过程可能时间稍长。一方面,可以默认仅复制上次更新之后的文件,减少复制时间。另外一方面可以通过减少目录的文件和层次达到,例如将大量琐碎的图片资源文件打包成一个zip文件,这样减少了文件的数量也就减少了复制的时间。

这个运行按钮也有一点点不一样,由于有些产品单元根本没有exe可以运行,例如平台的代码就没有,所以他通过让VS启动某个特定的Exe来启动调试,附加的好处是仍然可以使用VS的“编辑并立即运行”功能。

发布

发布包括内部发布和依赖成果更新两种,内部发布是指产品单元内部始终保持尽可能新的组件,通常的,内部发布的工作都是定时执行的,只是偶尔某个版本发布的有问题,我们才会手工执行一次发布的过程。他就是一个MSBuild的自定义文件,存放在特定的目录下,让TFS定时执行,他获取此产品单元的所有最新文件,签出bin目录,然后编译,确认无编译错误后签入最新组件。

依赖成果更新相对基础产品单元来说就是外部发布,对于上层产品单元来说是一次依赖成果的更新。当依赖的基础产品单元完成内部发布并确认无误后,向本产品单元更新最新成果的过程,过程是:

  • 下载依赖产品单元的最新bin成果,例如下载平台的最新组件;
  • 签出本产品单元bin目录,然后复制,例如具体ERP产品签出bin目录,再将平台的最新组件覆盖ERP的bin目录;
  • 签入最新组件。

由于这种更新必须是谨慎的,所以我们都是手工启动任务,他一样是一个MSBuild文件。

原文地址:https://www.cnblogs.com/tansm/p/DotProjectPractice_3.html