TFS源代码管理v10

整理文档很辛苦,赏杯茶钱您下走!

免费阅读已结束,点击下载阅读编辑剩下 ...

阅读已结束,您可以下载文档离线阅读编辑

资源描述

TFS源代码管理1.项目和解决方案的结构VisualStudio使用解决方案(.sln)文件将相关的VisualStudio项目(.csproj)文件组织在一起。确定如何设置项目和解决方案的结构是一项重要的决策,因为我们选择的模式会带来多方面的后果。例如,它会对我们的开发团队程序将解决方案和项目推入/拉出源代码管理的难易程度、用于引用依赖项的机制以及生成过程产生影响。1.1解决方案基于我们所处理的是具有大量项目文件的软件开发项目,应该使用多个解决方案文件,按照整个团队项目中的功能子集分组相关项目(即按照系统架构设计说明书中的功能子集分组)。所以,将应用系统拆分为多个解决方案,各解决方案内的所有引用都是项目引用。对各解决方案外部的项目的引用则是文件引用。如果程序集位于解决方案的项目集之外,但仍然想使用项目引用,则可以将原始项目的依赖项(被引用项目)分支到开发人员的项目中。当开发人员想获取新版本的依赖项时,通过执行从原始项目到分支的合并即可实现。如果开发人员由于需要引用当前解决方案的项目集之外的程序集而无法使用项目引用,并且不希望创建从原始项目到他的项目的分支,则必须设置文件引用。解决方案的创建必须由专人或各个项目团队Leader进行操作,其他人员无此操作权限。注:ASP.NET网站开发有WebSite和WebApplication两种编程模型,我们在项目开发中统一使用后者。1.2项目结构将来自所有团队项目的全部源代码放在一个文件夹下,例如D:\TeamDev\MES_V2.2\SourceCode。同时为每个团队项目创建一个子文件夹,如下例所示:D:\TeamDev\MES_V2.2\SourceCode根容器文件夹,包含所有团队项目\Platform平台团队项目的容器文件夹\Tool工具团队项目的容器文件夹\DataMaintenance数据维护团队项目的容器文件夹\AdministrativeApp管理应用团队项目的容器文件夹\ProductionApp生产应用团队项目的容器文件夹\Report报表团队项目的容器文件夹在各团队项目文件夹下使用的应用程序文件夹结构,如下例所示:\ToolTeamProject平台工具团队项目的容器文件夹\Main包含跨项目的.sln文件(如有需要)\FormDesigner包含FormDesigner.sln\Source\ClassLibrary1包含ClassLibrary1.csproj\WebApp1包含Default.aspx\UnitTest包含单元测试项目和源代码(如有需要)\ClassLibrary1Test\WebApp1Test项目结构的创建必须由专人或各个项目团队Leader进行操作,其他人员只能在创建好的结构下进行开发。解决方案下各项目结构要求详见“$/MES/DevelopmentLibrary/Doc/04开发文档/开发规范开发的各个层级命名.xlsx”文档。1.3分支TFS中的分支(Branching)是指把源代码控制系统中的文件和目录复制一份。分支能够保持文件和目录的历史,并且能够把旧的文件上的修改合并到新的文件上去。在新的分支上进行的修改,和原来的分支(一般称为主分支)没有任何关系。通常,分支创建用于推行一个发布、维护之前的发布或并行开发。除非有充足的理由,否则就不应进行分支。以下为几个常见的分支创建场景:1.如果开发时间紧迫,有可能需要进行并行开发,则应创建分支,主分支代码和分支代码同时开发。在某个时刻再将两个分支合并;2.如果功能需要细分,则在完成共同的基础功能开发后,通过分支来实现不同版本对应增值功能的开发。在某个时刻再将分支分别合并;3.如果有一些功能引起了稳定性问题,或者有团队导致了团队间的稳定性问题,则应创建团队分支,以使整个开发工作趋于稳定。在项目中我们使用3个分支对源代码进行管理,它们分别是:DEV分支:开发人员进行项目开发与单元测试;QA分支:测试人员进行系统与集成测试;UAT分支:联想人员进行验收测试。上述三个分支的创建必须由专人进行操作,其他人员只能在创建好的分支下进行开发。如果项目开发需要新建分支,必须向此人申请。1.4源代码管理1.4.1文件管理1.4.1.1需要进行版本控制的文件下面的列表识别了应添加到源代码管理的关键代码文件类型。应在单击“将解决方案添加到源代码管理”时将这些文件类型添加到其中。文件类型说明解决方案文件(*.sln)它包含成员项目的列表、依赖项信息、生成配置细节和源代码管理供应者细节。项目文件(*.csproj)它包含程序集生成设置、引用程序集(按名称和路径)和文件清单。VisualStudio源代码管理项目元数据(*.vspscc)它们维护项目绑定、排除列表、源代码管理供应者名称和其他源代码管理元数据。应用程序配置文件(*.config)可扩展标记语言(XML)配置文件包含项目和应用程序的具体细节,用于控制应用程序的运行时行为。源文件*.aspx、*.svc、*.cs等)源代码文件。二进制依赖项(*.dll)如果项目依赖于二进制依赖项,例如第三方动态链接库(DLL),还应在源代码管理中将其添加到项目中。1.4.1.2不应进行版本控制的文件以下列表文件特定于各开发人员,因此不应添加到版本控制中:文件类型说明解决方案用户选项文件(*.suo)这些文件中包含一位开发人员对VisualStudioIDE进行的个性化自定义操作。项目用户选项文件(*.csproj.user)这些文件中包含特定于开发人员的项目选项和可选引用路径,VisualStudio使用它来定位引用的程序集。WebInfo文件(*.csproj.webinfo)此文件跟踪项目的虚拟根位置。此文件不会添加到源代码管理中,以允许各开发人员为自己的项目工作副本指定不同的虚拟根。尽管这种功能是存在的,但建议所有团队成员在开发Web应用程序时都使用一个一致(本地)的虚拟根位置。生成输出包括程序集DLL、互操作程序集DLL和可执行文件(EXE)。1.4.2签入签出管理1.4.2.1签入TFS中的签入是指将本地对代码的修改(包括添加项目、添加文件、修改代码、修改解决方案设置等任何使受控制的文件发生了变化的操作)反映到服务器上,使其他团队成员可以立即获取到最新的源代码。1.4.2.1.1仅在准备共享代码时签入代码仅在完全通过单元测试并且准备与团队的其他人共享时,才能将更新的代码签入源代码管理中。对尚未完成的中间工作使用搁置集。当开发人员签入代码时,该代码将用作下一个预定生成的一部分。任何不完善的代码都可能导致生成不稳定。此外当签入代码时,执行“获取最新版本”操作的任何其他开发人员都将获取到此开发人员的更改。如果它们不完善或测试不适当,则它们将引起其他开发人员的问题。1.4.2.1.2使用搁置集备份或共享挂起的更改使用搁置集备份包含开发人员尚未准备签入的挂起的更改的文件。还可以使用搁置集共享代码以便查看代码,或者可以终止其他开发人员的开发任务。通过使用搁置集,开发人员可以将挂起的更改上载到服务器,而无需签入部分完成的工作,从而导致生成不稳定。开发人员可以在休息日前将自己开发的源代码通过搁置集方式上传到服务器保存,上班日再获取源代码继续开发,以保证源代码的安全。1.4.2.1.3在合并后、签入前生成并运行测试执行合并之后,确保在签入合并的文件之前,编译该代码并运行关联的测试。执行此操作可以避免由于合并导致生成不稳定。1.4.2.1.4每个签入解决一个可测试的功能点1.4.2.1.5避免冲突开始在一个文件上工作之前,确保从源代码管理中获得最新版本,并查看是否其他人已将该文件签出,然后再开始工作。使用VisualStudio合并工具解决合并冲突。如果在合并期间检测到冲突,可以自动或手动解决冲突。如果选择手动解决冲突,即可在合并工具中保留源更改、保留目标更改或解决冲突。解决了文件中的所有冲突后,将最终版本保存为要签入目标分支中的挂起的更改。进行合并时要格外小心,因为很容易发生一些导致生成不稳定的错误。完成合并后,编译所得到的源代码,并运行单元测试来测试主要中断。1.4.2.1.6签入备注开发人员在签入源代码在前,必须在签入注释栏内详细填写签入理由。如果代码需要审核,则必须告知审核人员并请求其审核源代码,审核完毕后,由审核人员在签入说明项的“CodeReviewer”栏中填写审核人员名称。1.4.2.2签出、获取和锁定1.4.2.2.1在进行更改前获得最新源代码要确保开发人员具有正在处理的项目最新版本的所有源文件,请首先运行“获取最新版本”命令,然后再签出文件进行编辑。不执行此操作的危险是,以后将文件签入服务器时,根据非最新源文件本地生成代码会增加代码引起生成问题的可能性。1.4.2.2.2签出时必须使用锁定命令如果开发人员担心存在冲突,从而导致手动合并操作更复杂,则应该只在进行编辑时锁定文件。如果想避免任何冲突的可能,请使用签出锁定,这会阻止其他人签出以及签入同一文件。1.4.2.2.3在锁定文件时要与同一团队中的伙伴沟通如果开发人员锁定源文件,需要让团队成员知道,以便他们可以围绕该文件的不可用性计划他们的工作。1.4.3发布与更新源代码的发布与更新主要针对QA与UAT流程。在这两个流程中,由于相关人员可能不熟悉项目源代码的发布规则与更新规则,有可能在发布与更新中出现错误,从而影响正常的工作开展。所以,需要由专人事先制定出针对这两个流程的发布与更新规则:1.由专人配置服务器IIS站点、服务项、计划任务等,并部署好数据库等所有系统正常运行所需要的应用与工具;2.创建自动化部署脚本,协助系统在发布与更新时将相关组件、服务项自动发布/更新到相应路径;(如有需要)3.制订发布计划,确保所有相关开发人员在系统发布前都能得到发布信息通知,以及时签入要发布的源代码;4.制订发布回滚机制与开发相应辅助工具,协助发布人员在发布失败或部分失败时能快速回滚代码到前一个正常运行版本;5.由专人通过既定的发布操作,将源代码编译后发布到预先配置好的环境中。1.5源代码开发流程设计详细设计详细设计Review是否通过程序设计程序设计Review是否通过否是是提交开发开发(DEV分支)实现功能单元测试是否通过代码迁入到DEV分支代码Review是否通过提交测试否是是测试(QA分支)在DEV分支执行测试用例测试是否通过是否与需求一致代码迁入到QA分支在QA分支执行测试用例UAT(UAT分支)是修改代码(DEV分支)否否是测试是否通过进入UAT流程是发布UAT通知联想人员进行UAT测试测试是否通过进入上线流程是修改代码(DEV分支)否否仅将此步骤的执行过程(做为整体开发流程的一个组成部分)进行演示性说明,具体执行过程由相关人员提供。否注:代码Review需要确定人员,确定标准待定。

1 / 6
下载文档,编辑使用

©2015-2020 m.777doc.com 三七文档.

备案号:鲁ICP备2024069028号-1 客服联系 QQ:2149211541

×
保存成功