XX_二代配置分支管理规范.doc

文档编号 XX_运维_0042 版 本 号 V1.0 密 级 内部公开 二代系统配置管理规范 XXX信息技术有限公司 版本控制 编号 修订人 修订时间 版本号 修订内容说明 1 2 3 目录 1 简介 4 1.1 定义 4 1.2 目标 4 1.3 范围 5 2 分支策略 5 2.1 稳定主干策略（The stable trunk） 5 2.2 不稳定主干策略（The unstable trunk strategy） 6 2.3 敏捷发布策略（The agile release strategy） 6 3 现状分析 7 4 配置管理策略 7 4.1 确定分支策略 7 4.2 代码拆分策略 8 5 配置管理规范 8 5.1 开发阶段 8 5.2 测试发布阶段 9 5.3 上线发布阶段 9 6 配置管理制度 9 1 简介 1.1 定义 概念 描述 软件配置管理(Software Configuration Management, SCM ） 是指通过执行版本控制、变更控制等规程，以及使用合适的配置管理软件，来保证所有配置项的完整性和可跟踪性。配置管理是对工作成果的一种有效保护。它是软件质量管理的重要组成部分。 配置项（CI,Configuration Items） 软件开发过程中的里程碑，它以一或多个软件配置项的交付为标志。基线由已经通过正式评审和批准的某规约或产品组成，它可以作为进一步开发的基础，并且只能通过正式的变更控制过程才能够改变。 产品配置是指一个产品在其生命周期各个阶段所产生的各种形式和各种版本的文档、计算机程序、部件及数据的集合。该集合中的每一个元素称为该产品配置中的一个配置项. 基线(BaseLine) 基线就是一个CI或一组CI在其生命周期的不同时间点上通过正式评审而进入正式受控的一种状态，而这个过程被称为“基线化”。每一个基线都是其下一步开发的出发点和参考点。每个基线都将接受配置管理的严格控制，对其的修改将严格按照变更控制要求的过程进行，在一个软件开发阶段结束时，上一基线加上增加和修改的基线内容形成下一个基线，这就是基线管理的过程。 (基线：是指在软件开发过程中的里程碑，这些里程碑的标志是一项或多项经过正式的技术评审并一致认同的CI的提交) 1.2 目标 软件配置管理的目标：通过使用配置标识、配置控制、配置状态记录及配置审计，来达到建立与维护工作产品的完整性、一致性和可追溯性。 1.3 范围 适用于公司二代软件产品研发项目 2 分支策略 分支策略一般有三种：稳定主干策略、不稳定主干策略和敏捷发布策略。 2.1 稳定主干策略（The stable trunk）     此种分支策略使用主干作为稳定版的发布。主干上永远是稳定版本，可以随时发布。bug的修改和新功能的增加，全部在分支上进行。而且每个bug和新功能都有不同的开发分支，完全分离。而对主干上的每一次发布都做一个标签而不是分支。分支上的开发和测试完毕以后才合并到主干。 这种策略创建分支的原则是：干线所放的项目数据是最接近准备发布的程序代码；而分支则用来进行开发、缺陷修复和发布前的质量保证以及重构。分支也可以用来开发试验性质的程序代码。     这种发布方法的优点是：任何时候都可以从主干获得发布版。每次发布的内容调整起来比较容易。如果某个新功能或者bug在下一次发布之前无法完成，就不可能合并到主干，也就不会影响其他变更的发布。另外，每个分支的生命期比较短，唯一长期存在的就是主干，这样每次合并的风险很小。每次发布之前，只要比较主干上的最新版本和上一次发布的版本就能够知道这次发布的文件范围了。    此种分支策略的缺点是：从分支合并回主干由非开发者的配置人员来做。另一方面：如果某个开发分支因为功能比较复杂，或者应发布计划的要求而长期没有合并到主干上，很可能在最后合并的时候出现冲突。另外由于对于每一分支都要进行测试才能够合并到主干中，测试工作量较大。 2.2 不稳定主干策略（The unstable trunk strategy）    此种分支策略使用主干作为新功能开发主线，分支用作发布，此种分支管理策略被广泛的应用于开源项目。主干永远是包括所有最新特性的不稳定版本，然后随着新特性的逐步稳定，达到一个发布的里程碑以后，从主干分出来一个稳定分支。每个大版本一个分支，每个发布分支上只有bug修改和现有功能的完善，而不会再增加新特性。新特性会继续在主干上开发。当稳定分支上发生的修改积累到一定程度以后，就会有一次发布。发布的时候会在稳定分支上再分出来一个发布( release)分支。此种分支管理策略比较适合诸如传统软件产品的开发模式，例如微软Windows开发，对于互联网开发不是很适合。 这种策略创建分支的原则是：主干应该包含最新的代码——无论是否稳定，而准备发布的版本应该被创建为分支来进行QA。 这种策略的优点是：合并比较好做，因为不需要经常合并，此外，合并是由了解代码的开发人员做的。 这种策略的缺点是：已经在主干上集成的新功能，如果达不到里程碑的要求，稳定分支就不能创建，很有可能影响下一个发布的计划。还有一个问题就是bug修改必须在各个分支之间合并。另，干线上的代码可能会包含好多缺陷，不太稳定，发布时准备时间比较长。 2.3 敏捷发布策略（The agile release strategy）     此种模式在采用敏捷开发模式的项目中广泛采用，这些项目有固定的迭代周期，新的功能开发都在任务分支(Task branch)上进行，在接近迭代周期的发布阶段时候，新建发布分支(Release branch)来完成本迭代周期的发布，各任务分支(Task branch)的功能合并(merge)到发布分支(Release branch)中，在完成发布后，发布分支(Release branch)的功能合并(merge)到主干(Trunk)和尚在进行的任务分支(Task branch)中。     采用敏捷发布策略的原则是：要求主干的版本任何时候都可以发布，在任何时候，产品所有者都可以基于主干的最新版本，发布新版本的产品。 策略分析：希望能够尽早发布，比较适合敏捷开发软件的要求，但对程序员及SCM要求较高。另外，这种策略目前在外企有比较多的尝试，但目前公司很难进行敏捷开发模式，小步迭代的开发方式也很难推行，所以无法采用。 3 现状分析 目前二代的配置管理存在的问题总结如下： 1、 配置控制没有做到位，代码库只有一条主干，且环境不稳定，不能编译通过，无法寻找到可发布的稳定的产品版本，导致开发人员不敢及时更新代码 2、 所有的开发人员都在主干上进行开发，未开发完成的代码也提交到了主干上。严重影响到技术人员的编译环境和QA环境部署的问题，从而引发技术人员无法在此基础上去开展新的任务。 3、 在开发调试过程中，由于不稳定主干环境问题只能注释掉其他人员代码使自己的代码能够编译通过。但由于开发人员提交不规范，出现冲突时直接覆盖版本库上版本。将注释掉的代码也进行了提交，导致他人代码失效等 4、 由于代码耦合性比较高，发布上线时总有代码冲突，需要拆分文件，给发布上线带来很大的成本和风险，从而影响发布上线速度 4 配置管理策略 4.1 确定分支策略 根据不同产品的研发特点，也需要采用不同的配置管理策略： 1、 变化较少，相对稳定的底层模块，采用不稳定主干的策略。 2、 变动频繁，经常要上线的模块，采用稳定主干的策略。 基于以上分支策略介绍及公司的现状分析，公司业务发展变动频繁，每天至少要做一次上线，要想解决以上问题建议采取稳定主干策略。另，通过此策略可以解决公司现状分析中除了第二条以外的问题。对于第二条工具不能彻底解决，需要配合一些其他的管理制度，解决办法：一方面：通过控制权限，合并工作只有技术组长或组内的技术负责人才有权限；另一方面：通过流程制度去规范约束。 初期我们的主干还是在不稳定环境下运行，一方面：因寻找稳定主干需要的成本比较高；另一方面：现在的发展情形随时都可能发生各种异常情况，从而给公司带来不同方面的影响，应尽快解决。故先假设某一时刻就为稳定主干，开始实施稳定主干策略，并同时预计一个月时间进行大规模的寻找趋于稳定的主干，保证两方面：一、能够全部编译通过；二、验收功能与生产环境一致。 4.2 代码拆分策略 目前公司所有的业务模块按工程划分，配置文件都为同一个文件，使得文件很大内容很多，这样必然增大了代码的耦合性及冲突代码产生的概率，同时也增大了代码注释以及覆盖的几率，使得人力成本投入很多，风险发生的概率也增大。其次，代码命名不规范，重名文件很多，虽说不属于同一个工程，但这样容易给人带来误区，也不便于管理。 改进措施： 1、 需要技术人员配合对代码进行拆分，按照功能模块或业务模块，对配置文件进行合理拆分，降低代码耦合性及影响范围，此环节需要邵金岭的大力支持，出具具体的改进实施计划。 2、 配置人员提供代码耦合性较高的文件列表 5 配置管理规范 5.1 开发阶段 1、 对于现有的CVS主干所有项目技术人员只有读的权限，只有配置组人员有提交修改的权限，并且开始调试各项目直到能够编译通过并测试功能没有问题，再发布到主干成为稳定版本。此时技术人员即可放心的从主干获取最新代码进行编译。调试过程需要各组组长大力配合 2、 开发人员每次接收到新的开发任务后，都要从版本库主干上取得最新的代码，并在此项目代码基础上开始任务开发。 3、 开发分支由技术人员自己创建，命名规则：开发人员用户名_创建日期_bug号（如果没有bug号，提供任务描述信息但不能为中文） 4、 开发人员以任务为单位提交代码，也就是以上线单为单位建立分支，把完成这个任务的所有代码或配置全部提交，提交时填写注释信息，写明完成的任务描述，以便查询和追溯。 5、 开发分支代码合并到测试分支由技术人员负责，如果出现冲突，必须找相关人员沟通确定，然后再进行合并，不得随意修改或注释他人代码。 6、 技术人员提交上线单时，需要提供开发分支名和代码清单。 例如： #wuml_2 /YP2G_CommonService/src/java/com/yeepay/common/valuelist/service/CacheValueListConfigServiceImpl.java /YP2G_CommonService/src/java/springContext/commonServiceContext.xml 5.2 测试发布阶段 1、 测试分支由配置人员建立。测试分支定期会重新创建，以最新的主干为基础，将未测试通过的开发分支由开发人员再重新合并到新的测试分支上，对于每次测试分支的发布会邮件通知所有技术人员。 2、 测试分支命名规则：test_日期 3、 配置人员按照增量的形式从测试分支上按照技术提交的代码清单提取文件，并编译打包部署到测试服务器。 4、 重启测试服务器，转交流程，通知测试人员测试。 5、 测试阶段有更新时，重复3过程。 5.3 上线发布阶段 1、 配置人员创建发布分支，命名规则：release_日期。 2、 根据上线流程制度，区分上线和不上线的任务，将上线任务所对应的开发分支提取合并到发布分支，然后按照所有上线的代码清单，从发布分支提取文件进行上线。 3、 上线结束后，配置人员将上线的代码任务合并到主干，并打一个标签，命名规则：tag_日期 6 配置管理制度 1. 对于未开发完成任务或未自测通过项目的开发分支，不得提交合并到测试分支，以免带来不必要的合并工作，及给QA部署带来麻烦，若发现此现象则由技术负责人或组长承担责任。 2. 每次bug更新等开发人员必须在自己的开发分支进行修改，然后再合并到测试分支，不得在测试分支直接进行代码开发及修改，发现一次进行相应的处罚。 3. 开发人员从开发分支合并到测试分支过程如出现违规操作（不顾版本冲突，直接覆版本库的版本；不与他人沟通直接注释或删除掉他人代码的做法等），使得他人代码失效，则由造事者承担责任。 4. 上线发布时，是从开发分支提取代码，所以开发人员必须是以任务或上线单为单位创建分支，不能有搭车或其他上线单功能的修改，从而造成上线出现问题，一旦发现，则有造事者承担责任。 5. 各配置库的使用人员必须使用各自的用户名和密码进入配置库，且访问授权的配置库。各使用人员不得将自己的用户名和密码泄漏给其他人员，若因泄露密码而引起的后果将由泄漏密码者本人承担。 6. 在技术人员离职时，由其技术组长检查配置库，检查该人员提交的代码或文档是否完全放入配置库管理，确认版本和相应文件完整无误，并通知配置管理员，消除该技术人员用户名取消所有权限。若因技术组长未进行检查或未及时通知配置管理员取消权限，而造成的损失，该责任完全由技术组长承担。 7. 在配置库使用时，为了避免配置库检入或检出时引起冲突，需注意技术组长或技术负责人在划分模块项目时，注意每个人之间尽量不要重叠。 8. 分支命名必须遵守规则要求，如发现有不合规操作，则直接打回且由造事者承担责任。 第 11 页 共 11 页