跨越鸿沟——从实践角度看软件配置管理

    最近一年多来，大江南北的到处跑，和数十家软件企业面对面的探讨了其在软件配置管理领域的实践中所面临的问题以及可能的对策，总结后发现其中有若干问题颇有共性，故集结成文，以飨诸位。

鸿沟——从理论到实践的畏途

    软件配置管理无论从理论还是方法，算是整个软件过程体系中一个相对比较丰富和成熟的过程域了，记得几年前曾经在某咨询公司就职的时候，公司给推荐了一个软件配置管理的培训教程，从配置管理计划到配置审计，从配置项标识到构建发布，洋洋洒洒将近200页的PPT，堪称一篇学院派软件过程的经典教案。但是用了一次之后就不得将之束之高阁，因为培训完后大家的综合反馈是：内容丰富而详实，且循序而渐进，普遍接受度和满意度均颇高，但唯一的一个问题是还是不知道如何将这些理论和方法真正落实到具体的开发实践中去。郁闷之余，细细反思后发现我们：软件配置实际是一个操作性很强的过程域，而被我们奉之为经典的软件配置管理理论及方法体系在大多数情况下并不能那么顺利的被拿来指导我们的开发实践（拿来指导我们的CMMI过级实践倒往往是游刃有余）。实际上，大多数软件企业的软件配置管理依然停留在版本管理的初级阶段，虽然其中不乏通过CMMI评审的软件企业。 而和实践脱节的理论和方法充其量只能是一盘卖相精美且可饱口舌之欲却不能用以果腹的水果拼盘而已。

    ——理论和实践的脱节是软件配置实践中面临的最突出的问题

    下面，针对软件配置管理实践中往往被忽略但却非常重要的若干环节做一些讨论：

配置策略

    “策略（Strategy）”往往被认为是一个很虚幻的名词，在大多数情况下，这个单词甚至一次都不会闪现在配置经理的大脑中。显然，这是一个被严重忽略的环节——而实际上，选择适当的配置策略是整个软件配置管理体系成功的关键。那么，究竟什么是软件配置策略呢br>    比方说，你要从A地出发到B地旅游，在出发以前，首先要综合考虑诸如支出、身体状况及时间等诸多因素，进而从众多可选的路径中选择一条最为合适的路径，然后再着手具体的细节，如选择航班，预订酒店等等。
    在软件配置管理中，对于变更的控制策略就是一项最基本的配置策略（参见：http://microke.cn/14）
    其他典型的配置策略包括：配置域的划分策略，分支策略，访问控制策略等等。（不在此一一详述，考虑以后逐步整理一些相关内容在此发表）。
    很多企业在规划企业配置管理体系的时候往往觉得头绪很多，不知从何入手——而配置策略的逐级深化就是构建一个有效配置管理体系的一个最好的线索。

并行开发

    并行开发在大多数软件企业中被视为畏途，因为分支及合并往往会衍生出一堆没完没了的麻烦，而不少企业本能的选择了一个懒人（虽然懒人有时候是智慧的，但并不总是）的方法——即尽量规避并行开发，但这样做除了会对开发的管理及代码的质量带来诸多负面的影响外，更要命的是，有些情况下并行开发是避无可避的，如已经交付客户且需要长期维护的旧版本等等。
    因此，并行开发的规划和管理在软件配置管理中是一个非常重要的环节（事实上，现代配置管理工具区别于VSS之类上一代工具的最大特征就是以并行开发而非加锁的方式来处理并发的软件开发）。但是由于配置管理的特殊性（主要是其对工具的依赖程度很高），脱离具体工具抽象的来谈并行开发管理往往是毫无意义的。必须结合具体的工具对并行开发进行有效的规划和管理。
    （相关内容不在此详述，考虑开个专栏就Subversion环境下实现有效的分支结构模式和控制策略进行讨论）

工具的选择和使用

    无论是大型的商业软件还是开源软件，软件配置管理工具的可选项都是相对较多的，关于这些工具的性能比较有较多文章，就不再赘述，在这里主要从如何选择及使用工具的角度出发做一些探讨。

    首先要考虑的，毋庸置疑的是成本。这里说的成本，是指全周期的成本，除了采购的费用，还包括相关的培训和维护费用。前段时间我们曾经为一个大型的通讯公司提供服务，帮助其从ClearCase转移到Subversion，该公司如此大动干戈的迁移配置库就是因为购买的License数量远远少于实际使用的用户而收到了IBM的律师函（老外是不会永远在那里放水养鱼的，早晚有一天会下 捞鱼的，尤其是对于有点名头的大鱼）。

    其次需要考虑的就是工具本身的约束。工具在实际应用过程中往往具有两面性，即除了对你的过程提供支持以外，还会对你的过程带来一定的约束，而这种约束有些时候往往是负面的，而越是“高级”（这里所谓的高级，可以理解为对过程的抽象程度高，如UCM之类的“模型”）的工具，这种负面的约束越大。

    另外一个很重要的因素就是可扩展性和可定制性。虽然通常几乎所有工具厂商都会声称其产品是史无前例且无所不能的，而那些西装革履的售前工程师们也一定会反复的拍着胸脯保证其产品在任何场景下都能游刃有余，但有一点是永远不会改变的，商品化的产品必须卖出足够的拷贝数量才能收回其庞大的投资并获取利润，所以这样的产品必须具有通用性，在为了实现这样的通用性，必须对各种不同的需求进行一定程度的抽象。因此，其满足的往往是抽象后的需求，而不是这样那样具体的需求。通常，仅仅靠一份QuickStart文档和一些简单的培训及支持服务，离大功告成还差着十万八千里呢——一切仅仅是个Start而已……。要想真正的建立起一套真正有效的软件配置管理体系，必要的扩展和定制是必不可少的。至于开源软件（如Subversion），虽说上手很容易，但其快速构建的只能说是版本管理，而离配置管理依然任重而道远。