版本管理

    本文的版本针对 代码文件 的版本控制。 基于  瀑布式 与 敏捷 结合的开发模型 下的版本规划。支持迭代和反馈，能在一定程度上灵活响应市场和需求的变化，兼顾了 版本质量与版本发布的实时性。

    版本管理流程包括：版本计划制定与审核、版本开发、版本生成、版本测试、版本发布、版本维护。上述各过程也是串行执行的。

 

版本管理计划

      项目有时会在立项时制定版本管理计划，定义了版本管理有关的过程。包括版本号的编排计划、版本经理、版本计划的审批人、。。

    

版本计划制定与审核

    版本计划由版本经理制定，由项目经理、产品CCB审批。

    影响版本计划的因素包括：需求的工作量（文档开发工作量、代码开发工作量）、项目进度计划、面对的市场项目的进度、需求的优先级、关联项目的版本计划、开发与测试的人力资源。。。

  

1 产品、项目与版本 的关系

        一个产品的生命周期可能多达10年或更长，其中主要的开发周期可能长达5年，之后才进入成熟期，主要以维护故障和小需求变更为主。

      如以5年周期来立项，这个时间点明显是无法适应公司管理和市场需求的。一般至多以一年为周期来立项。每个项目都包括了若干版本。

      一个项目立项后，一般会分为多个大版本，每个大版本内分为若干小版本。版本的命名比如:V3.01.10，V3表示这是本产品的第3个项目周期，01表示这是本项目周期内的第一个大版本，10表示大版本内的某个小版本（可能以01,02..顺序排列，也可能以10,20,..顺序排列）。 (注：也可能有其它命名、编号方式)

      在小版本之内，还分集成测试版本、系统测试的若干版本。比如V3.01.10.I1，I1表示这是本版本的第一次提交集成测试，V3.01.10.B2表示这是本版本的第三个系统测试版本。

     比如项目计划制定了I1\I2\I3三个I版本，每个I版本都经过一轮测试周期（由开发部门进行），同时解决故障后，制作下一个I版本，再进入一个轮回，最多到I3版本后。进入B版本周期，此时测试工作转交专门的测试部门，经过多轮测试、解决故障并制作版本后，到某个B版本时，本版本的开发、测试工作截止，项目线进入下一个版本周期。

    

    有些 没有需求变化、进度不急迫 的项目可以按上述所指的每个版本进行立项，这样产出的产品质量较高，但项目管理成本太高，一般项目承担不起（ 投入产出比不高）。

    一般：立项初制定的版本规划与任务进度会预留较大余量，分版本实现立项需求、故障优化。

    基线化后来的新需求，视轻重缓急将其规划到已规划的版本中，避免影响现有版本规划、开发任务与测试任务进度。

    紧急需求紧急调整版本规划与任务进度，甚至紧急测试后发布紧急版本（不合入主干版本分支）。

    这种版本规划方法兼顾了 版本质量与需求实现的及时性，实现了 研发效率与需求管理过程 的折衷。

 

    每个版本都要兼顾 需求实现、故障优化 两大主线，这不仅保证了用户需求的及时（可控的）实现，也保证了发现的版本质量问题及时（可控的）解决。

 

    每过一段时间，为特定局点定制的版本中的特定功能，会被要求合入主干版本。产品总是维护一个主干(或主流)版本，即使这个版本不供任何局点使用也是这样。(因为特定局点定制版本总有一天会被放弃，区分特定版本、主干版本在产品的敏捷性与可维护性上取得平衡）。

 

2 小版本举例

   以XXX产品某项目计划的 V3.01.10版本 举例：

        基础计划:

                    基线版本：本版本基于V2.05.30.B6版本，表示：本版本的代码取自上述版本的代码路径。

                    开始日期：2010/5/1

                    发布日期：2010/6/21

                    发布版本号：V3.01.10

                    版本用途：A国家A1项目、B国B1项目，或通用版本。

                    版本文件存放路径：http://abc.com/xx产品/V3.01.10

      时间计划:含版本号、版本制作时间、版本期望测试时间周期 的对应关系。

                    V3.01.10.I1   2010/5/1 10:00、一周

                    V3.01.10.I2   2010/5/10 10:00、一周

                    V3.01.10.I3   2010/5/20 10:00、一周

                    V3.01.10.B1   2010/6/1 10:00、一周

                    V3.01.10.B2   2010/6/10 10:00、一周

                    V3.01.10.B3   2010/6/20 10:00、一周

            关联产品、关联项目的版本号：本项目代码中可能使用了其它项目的代码库（且这个代码库仍由其它项目维护），本项目必须与其它产品的xx版本才能协同工作。

                    V3.01.10.I1    X项目的V2.05.30版本。Y项目的V5.10.02.B3版本，Z项目的1567号补丁

                    ....

          功能点列表：

                V3.01.10.I1   需求x、y、Z，内部优化功能点A，205678号故障单。

                        有时这里会细化到每条需求的需求负责人、开发负责人、测试负责人、入库时间点、代码单号。

      V3.01.10.B3作为本版本的最后一个子版本，将对外发布（可以是对其它项目，也可以是对市场项目），对外的版本号称为V3.01.10（也可与内部版本号完全不同）。

        版本文件存放路径指定了本版本的代码所存放的文件服务器的路径，只需要为这一个版本维护一份版本，不需要为I1\I2..B1\B2\B3 子版本分别维护代码。从这个路径上取到的代码永远是本版本最新的版本。

 

3 版本编号

    版本编号非常重要，一旦一个产品立项，在这个产品的10年生命期内版本编号计划(分对内、对外)最好不要改动。它与文件存放路径有对应关系。

        比如：如果在版本计划中指定V3.01.10.B3的对外版本号是V3.01.A，那么当现场这个版本出现故障后，有开发人员（一般不熟悉版本计划）可能认为它对应的内部版本号是V3.01.01。

        比如：如果在版本计划中指定V3.01.10.B3的下一个顺序版本号是V3.01.10.B3a(原版本文件路径)，开发人员会不确定这个版本是新拉出的代码分支路径，还是在原代码分支路径上，在代码入库时可能入错。笔者碰到这种问题不止一次。

 

        版本编号在不同文档中必须一致，需求跟踪表、需求追踪表 中也存在版本号，可以填V3.01.10，也可填子版本号V3.01.10.B1。

        版本计划内含的需求名称必须与 其它文档一致：需求跟踪表、需求追踪表、用户需求文档、产品需求文档、设计方案、测试方案、版本说明书、版本升级指导书。。。。

        版本计划内含的需求，有可能是用户需求级别，也可能是产品需求级别。由于一条用户需求可能含多条产品需求，可以跨两个子版本分批提供。版本计划内必须考虑如何说明需求的级别。

 

4 版本的并行维护

    一个项目内的多个版本，从时间上看，不仅有串行关系，也有并行关系。

    V3.01.10版本的下一个版本是V3.01.20版本，但从V3.01.10.B2与V3.01.20.I1版本制作的时间点是相同的，即项目上同时进行了 V3.01.10、V3.01.20版本的开发、测试工作。

    原因是：V3.01.10版本给A、B国用，而V3.01.20版本发布给C国，但面对的市场项目的时间点并无串行关系。不同国家要求的需求不同，有时同一个功能在两个国家采用不同的接口、不同的业务流程，这里采用不同代码版本来支持。

    项目上不仅为多个国家分别维护一个版本，也同时维护一个通用版本。所有国家的所有需求对应代码在入到这个国家版本的同时，也会入到通用版本中，比如上述提到的一个功能在两个国家的接口不同，在通用版本中同时支持，但用网管开关来控制产品外在流程。

 

    面对的市场项目越多，市场需求越多，需求变更越多，版本计划就越复杂。笔者曾经碰到5个版本同时进行重点开发的场景，作为版本经理需要指定同一份代码最多同时合入5个版本，因为不同版本的作用不同，每一份代码变更要分析影响面，并考虑是否要合入每个版本。

    至于同时维护的版本号，更加不可计数。重点开发的版本需要对每一次代码变更考虑是否合入，非重点开发的版本只需要考虑特定功能的合入。

注：版本中不仅包括了需求引起的代码变更，更多的是解决故障、内部优化引起的代码变更。

 

    有时已经发布给某项目3年之久的版本也可能碰到需求变更场景，这时碰到问题是：是用当前最新的版本到现场升级，还是在现场版本上只增添一个功能。

    可能碰到的问题包括：

            现场版本的代码因为时间太久，已经无法完全找全（比如代码存放的服务器发生了迁移，版本管理员已经换了很多轮，本项目版本所依靠的其它项目代码 因为不在本项目中维护，需要联系其它项目获取，版本编译脚本或版本编译方法 因为发生了重大变化，当初的版本编译脚本已经找不到了）。

            现场版本是否可以提供热补丁。

            现场版本中隐含了某个重大故障，而如果用当前版本升级的话，当前版本合入很多功能，也可能引入新的故障，当前版本的一些功能可能与现场版本的流程不符（此时已经无人了解现场用户所需业务流程为何了）。

            ...

 

版本开发

        开发经理按版本计划下达开发任务，每个开发任务必须在版本计划指定的日期前入库并完成自测、集成测试工作。

        每次代码的修改、新增、删除，都必须由开发人员提交代码变更单，其中说明代码影响的版本分支、重点需求、业务流程体验变化，供CCB（版本经理牵头）考虑批入哪个版本分支，入完库后由集成测试人员验证通过。

        在每次版本制作之前，版本计划中要求的功能点都必须入库并集成测试通过。开发部或版本经理 会编写 版本说明书，描述了版本所含变更单、所含主要功能点、各功能点的简要说明、业务流程有哪些影响、在配置与测试时有什么特殊要求。。。

 

版本生成

     版本制作前，测试经理给出版本复盘报告，总结目前版本中仍存在的故障。如认为不影响主要功能，则结论为：版本可接受，否则版本规划可能推迟，直到重大故障解决为止。

     版本经理会提交版本制作申请，在版本管理员编译版本完成后，版本经理要求测试经理对这个版本中包括的所有代码变更单进行测试验证。如验证不通过，系统测试人员可以提交故障单，或对原有代码变更单走拒绝流程（视项目的故障管理流程而定）。

 

版本测试

        测试经理在版本测试结束后，会提交 版本测试报告与测试结论、或版本复盘报告，总结目前版本中仍存在的故障。如他认为本版本中含较多、较严重的错误（根据故障单的等级、个数而定，这也是版本管理计划的内容），则测试结论为不通过。可能触发项目经理、CCB牵头讨论故障出现的原因、是否是资源不足、是否是需求含糊、是否是开发人员技能、工作态度上不过关等等。另外：版本规划可能推迟，直到重大故障解决为止。

      如测试经理认为不影响主要功能，则结论为：版本可接受。则项目线认为这个版本可以对外发布或进入下一轮版本周期。

        每个版本中包括的代码变更单，经常有系统测试验证不通过的情况，这需要触发开发人员重新修改，修改后代码经版本经理批准到下一个版本中，由此开始新一轮周而复始的 提交代码->发现故障的->修改后再提交 的过程。

        每个代码变更单必须有不同的状态，标识其所处的流程节点。

 

版本发布

    在版本测试通过后（这里的版本一般是一个版本分支的最后一个版本号，如上文中的V3.01.10.B3），版本需要对外场的市场项目发布。

    针对所需要发布的局点，发布之前测试人员模拟现场环境进行模拟升级，并进行回归测试（覆盖此局点的全部需求场景）。

    测试成功后，测试人员需要编写 xx局点xx版本升级指导书、xx局点xx版本升级申请单，先经项目经理审批后，再提交现场服务部门，经后者审批通过后，把版本发到现场进行升级。

    升级期间（一般是深夜），故障经理值守，对现场在升级中可能出现的问题进行协调解决。

 

    如涉及硬件版本的升级、产品在某个客户局点的第一次版本发布，需要经过转产流程，即由生产部门来安排：生产硬件版本、组装产品、安装软件，并进行指定需求场景的测试，通过后再发布。

 

      版本发布、外发的评审、决策应该慎重，开发、测试、服务、质量、市场各代表对现存故障进行仔细分析，讨论现存故障的影响面，决策其是否能对某局点发布，明确版本的新增功能，解决的问题，遗留的问题，编写 升级安装指导。

      本项目版本与其它关联产品、项目版本的适配性，应该特别标明。确保各网元版本之间兼容匹配。

      版本外发评审通过，电子流程被批准后，外场服务部门才有获取版本的权限。

    

版本维护

1，版本外发

         外场某局点需要产品版本时，要提交 版本外发申请单。

 

2， 收到外部故障

        外场故障反馈给质量经理、故障经理，并触发版本经理安排：补丁版本、临时版本或紧急版本 的制作，正式版本计划也可能变更以容纳这个故障的解决。

        发生重大故障无法紧急解决时，可能触发版本升级流程、原版本在其它局点的废除流程，质量经理组织复盘，分析故障的发生原因，提交整改意见。

 

3，收到内部故障

      内部测试人员平时测试中发现故障，以故障单形式提交。

 

4，版本经理日常工作

     版本经理每天组织CCB会议，与开发经理、测试经理讨论每张内部故障的处理意见：指派处理或不处理（无故障拒绝、挂起、或故障存在不修改）。

     外部故障也需要在CCB会议上进行决策。会议上也会讨论故障的解决期限、需要入的版本、重大故障可能会影响版本规划的变更。  如故障同时涉及其它项目（如底层平台项目、协议项目、网管项目。。。），经常需要其它项目的版本经理参与，明确故障需要合入的时间点与版本对齐问题。

     版本经理平时的工作包括跟踪现存故障的解决进度，如发生拖延、扯皮、或未处理情况，应及时通报有关人等讨论解决方案。  部分故障涉及其它项目也需要跟踪其正确合入指定版本。

     在每个版本制作前几天，版本经理会特别关注 之前曾要求合入本版本的故障 是否已经把代码入库、集成测试完成并通过 等情况。

    故障预警机制： 发现重大故障时，版本经理安排人员分析  已商用局点的版本 是否也存在同样问题，如存在，则提请高层CCB进行决策是否对外场局点升级版本、发布补丁版本。

     对外发布后的版本进行跟踪，定期进行总结，评估其是否可推广使用或替换、升级到新版本。

 

5，版本复盘

        版本测试完成后，测试经理总结当前已发现的故障，分出严重一般故障，列出清单。发给开发经理要求分析产生原因、并给出改进措施。

        版本经理主持复盘，可能会发现一些由于软件过程不规范而导致的错误，比如需求未明确、异常情况未考虑到、由于不熟悉代码而产生的错误、自测\集成测试阶段应该发现的错误。

      复盘目标是：深刻的反省，找到自己环节（开发、测试）的薄弱环节，给出改进措施。关注缺陷为什么会产生，应该在哪个环节卡住、通过规范开发流程是否能解决，避免同类问题的再次发生。