软件版本控制规范.doc

软件版本控制规范Date of Issue: 2012/08/06Version: 1.0 For All Team MembersRevision HistoryDateVersionDescriptionAuthor2011-08-06draftEfun2011-08-20draft调整了文档的结构，增加了版本控制相关的内容Efun1目的12适用范围13职责13.1开发人员13.2发布人员14工作程序14.1项目开发人员注意事项14.2版本管理策略2软件版本控制规范 1 目的 规范部门软件产品版本升级流程，清晰管理版本号，加强不同版本软件保存的可靠性。 2 适用范围 适用于开发结束进行测试或投入应用的软件系统的升级或变更管理。 3 职责 3.1 开发人员开发人员负责代码的开发，开发的代码需提交到正确的svn地址。3.2 发布人员发布人员负责代码的发布，发布的代码需根据release note从svn获得，发布后需向所有相关人员发送成功的邮件，并更新JIRA上的状态。4 工作程序 4.1 项目开发人员注意事项4.1.1 开发人员每天早上至少从svn上update一次代码，下班前需再次update代码后，将修改的代码commit到svn。4.1.2 开发人员更新或提交代码时如果发现有代码冲突，需立即找代码冲突的相关人员查找原因，严禁直接强制提交。4.1.3 发布代码到uat和生产机需由专门的发布人员操作，每次发布到uat和生产机，需在JIRA上登记。4.1.4 发布人员只接收release note，发布人员根据release note从svn拉下代码并打包，不接收开发人员拷贝的代码文件。4.1.5 发布代码到生产机需根据release note生成check list，由开发人员和发布人员根据check list检查无误后进行发布，release note和check list的结果需在svn上留档。4.1.6 发布生产机成功后，发布人员需向所有相关人员发送成功的邮件，并更新JIRA上的状态。4.2 版本管理策略4.2.1 代码分支的管理4.2.1.1 代码分支管理示意图参见图4.2.1.1图4.2.1.14.2.1.2 代码分支管理策略在使用版本控制系统时，必须考虑如何设置分支结构。可以通过镜像源代码文件来创建一个分支。然后，可以在不影响源的情况下更改该分支。例如，如图4.2.1.2.1的分支结构所示，MAIN 分支包含已通过集成测试的已完成功能，而 DEVELOPMENT 分支包含团队正在构建的代码。当 DEVELOPMENT 分支中的新功能完成并可通过集成测试时，可以将代码从 DEVELOPMENT 分支提升到 MAIN 分支中。此过程称为“反向集成”。反之，如果将代码从 MAIN 分支合并到 DEVELOPMENT 分支中，则此过程称为“正向集成”。图4.2.1.2.1分支和合并需要遵循下列原则：1.每个分支都必须具有一个定义的策略，此策略与如何将代码集成到相应分支中有关。例如，在图4.2.1.2.1的分支结构中，可以指定一个团队成员来拥有和管理 MAIN 分支。该成员负责执行初始分支操作、将更改从 DEVELOPMENT 分支反向集成到 MAIN 分支，以及将更改从 MAIN 分支正向集成到 DEVELOPMENT 分支。当 MAIN 分支也从其他分支集成更改时，正向集成非常重要。2.MAIN 分支必须包含已通过集成测试的代码，以便始终准备进行发布。3.由于团队成员会定期签入更改，因此 DEVELOPMENT（或工作）分支将不断演变。4.标签(tag)是分支中的文件在某个特定时间的快照。反向集成和正向集成的频率：反向集成和正向集成应至少在用户情景完成时进行。虽然每个团队对于完成的定义可能不同，但完成用户情景通常意味着完成了功能和对应的单元测试。只能在单元测试验证 DEVELOPMENT 分支的稳定性后反向集成到 MAIN 分支中。如图4.2.1.2.2所示。图4.2.1.2.2如果具有多个工作（即 DEVELOPMENT）分支，则当任意分支集成到 MAIN 分支时应立刻正向集成到所有工作分支。因为 MAIN 分支保持稳定，所以正向集成是安全的。工作分支中可能会发生某些冲突或失败，这是因为无法保障工作分支是稳定的。应尽快解决所有冲突，这非常重要。4.2.1.3 添加分支的时机以下情况下应创建分支：在必须按与现有分支不同的时间表/周期发布代码时。在代码需要不同的分支策略时。如果创建具有新策略的新分支，则可以为项目增添策略价值。在向客户发布功能且团队打算进行不影响计划的发布周期的更改时。不应对每个用户情景创建分支，因为这会产生较高的集成成本。虽然通过 可方便地进行分支，但在分支很多时，管理分支的开销可能会很大。4.2.1.4 从版本控制的角度，关于发布的管理团队应能在任意冲刺 (sprint) 末尾发布代码。可以标记(tag)一个分支以在某个特定时间点为代码拍摄快照。如图4.2.1.4.1所示，可以为发布标记 MAIN 分支。这样，就可以将分支返回到此时间点时的状态。注意只有已反向集成到MAIN 分支的代码才能被发布。图4.2.1.4.1在为发布创建分支时，应从 MAIN 分支（该分支最稳定）创建分支。如果从工作分支对发布进行分支，则会导致集成问题，因为无法保证工作分支的稳定性。4.2.1.5 分支或标签(tag)的命名版本号Smartphone_20110905代号ab代号说明a项目代号，首字母大写，推荐使用驼峰式命名。b创建日期，4位年，2位月，2位日，位数不够补0。例：Smartphone项目在2011年9月5日创建了一个分支，则分支命名为Smartphone_201109054.2.2 版本号的含义版本号3.5.0.0vi-update1.0.0代号abcdefgh代号说明a大版本号，代表一次重要的系统升级。上线前为0，上线后从1开始计数，每一次重要的系统升级后计数加1。b小版本号，代表一次比较大的系统升级。从0开始计数，每一次比较大的系统升级后计数加1。c次版本号，代表一次生产机系统更新，如CR，或bug的修复。从0开始计数，每发布一次生产机后计数加1。d内部版本号，代表一次测试系统更新。从0开始计数，每发布一次测试机后计数加1；次版本号计数加1时，计数归零。e只在非主干分支上标示，代表开发的项目代号f只在非主干分支上标示，对应开发的项目的第几个分支。从1开始计数，对应开发的项目每创建一个，计数加1。g只在非主干分支上标示，分支次版本号，代表一次生产机系统更新，如CR，或bug的修复。从0开始计数，每发布一次生产机后计数加1。(一般开发分支需要合并到MAIN分支上才能发布到生产机，只有当开发分支代码独立为一套新的应用，在生产机上有新的url访问路径时，才能发布到生产机)h只在非主干分支上标示，分支内部版本号，代表一次测试系统更新。从0开始计数，每发布一次测试机后计数加1；次版本号计数加1时，计数归零。在不造成误解的前提下，沟通时分支版本号可使用简称，简称只取e、f、g、h位。如果基于分支又打了一个分支，则版本号在原来分支的基础上再增加e、f、g、h位，以此类推。例：假设原来生产环境的代码在MAIN分支上，版本号为3.5.10.0，现在有一个名为 NewProject的项目，且NewProject项目在生产机有自己新的url，则：基于MAIN分支3.5.10.0新建的第一个开发分支的第一个测试版本为3.5.10.0 NewProject 1.0.0，简称NewProject 1.0.0第一个开发分支的第二个测试版本为 3.5.10.0 NewProject 1.0.1，简称NewProject 1.0.13.5.10.0 NewProject 1.0.1测试通过后放到生产机，则第一个开发分支的生产机版本也为3.5.10.0 NewProject 1.0.1之后，基于3.5.10.0新建的NewProject项目第二个开发分支的第一个测试版本为3.5.10.0 NewProject 2.0.0，简称NewProject 2.0.0第二个开发分支的第二个测试版本为 3.5.10.0 NewProject 2.0.1，简称NewProject 2.0.1最后第二个开发分支的代码合并到了第一个开发分支，之前生产机累计已发布2次，对合并的代码内部测试3次通过，允许发布到生产机，则生产机最终发布版本为3.5.10.0 NewProject 1.2.2（生产机第3次发布，内部测试3次）4.2.3 服务器发布顺序参见图4.2.3.1图4.2.3.1