随着人员规模、产品数量、发布频率的急剧增长，配置管理的各个方面将面临若干挑战和机遇。本文将为你呈现当组织处于上述阶段时会面临的几个主要问题，以及需要对流程和工具所做的改进。
”
2004开始我负责带领我目前所处公司的配置管理团队，而这也是一项让我十分起劲的工作。我将在本文中分享一些个人经验，希望有助于读者迅速成长为配置管理老司机。
一开始我们只是个小公司，拥有约40名调研、开发人员，两条产品线，发布周期也很长。此时我们的配置管理相当的简单：一个当时流行的源码管理软件，一个老旧的、几乎没人用的缺陷跟踪工具，以及一些可读性像鬼画符一样的shell构建脚本。由两名配置管理工程师组成的团队足以应付一切。
一年过去了，公司业绩良好，雇员数量也稳步上升。所幸的是我们团队只需要确保软件有足够的license分配给新员工即可，管理层无需为配置管理争取更多的预算。由此得出我的第一条经验：
1.管理者雇用更多开发人员时需要注意由此产生的配置管理相关的开销。
我们配置管理团队遇到的第一个挑战就是那个缺陷跟踪工具。该工具已不再维护，也没法购买更多的license，再加上其巨难用、几乎无法定制化的劣势，寻求替代已迫在眉睫。我们很“理所当然”地把目光投向了我们源码控制工具的供应商所提供的一个先进的缺陷跟踪工具。该工具本身比较昂贵，配套的硬件升级进一步增加了使用成本，但我们有足够的预算，事实也证明了我们是做出了一个多么英明的决定。采用了该工具后，报告跟踪缺陷、生成各种报表、定制化数据和业务逻辑，这些工作忽然变得非常轻松。由此得出的第二条经验：
2.工具的定制化必须纳入管控。
很多用户会带着各种各样的需求和建议来找我们，有些是相互冲突的，有些则会产生意想不到的副作用。例如，有个团队主管想进行一些字段调整，而那些根本用不着这些字段的团队就会比较抵触。最终我们对配置管理工具定制化的需求进行了分级，需求只有经过了分级我们才去实现。
几年后我们被一家大型企业收购，此后事情就变得非常有意思。我们开始开发新产品，并为现有产品添加大规模的新特性。调研开发人员急剧扩充，人员规模有时甚至能在一个月内增加10%。
在这种增速之下，我们这个配置管理小团队要做的事情一下子就多了起来。我们需要持续评审并改进以下三项内容：工具的可扩展性、流程、成本。多数工具的可扩展性其实相当容易理解：更多的用户意味着更频繁地产生更多的数据，因此，请确保你能够：
3.对工具底层的数据库及文件系统进行扩容，支持更大的并发量，同时还能够满足一定的性能。
说白了我们需要做的无非就是采用更牛掰的硬件，以及确保工具本身支持这种可扩展性。
由于我们所使用的的源码控制工具和缺陷跟踪工具本身就是商业版的，我们只需要对服务器硬件进行升级。与其对硬件进行多次小幅度的升级，我们决定一次性采购一些特牛掰的服务器以支撑我们未来五年的需求。直到现在我们依然觉得我们当时又做出了一个多么英明的决定，在那以后我们不再需要定期清理空间或排查性能问题，给我们留出更多时间去处理其他事情。顺带一提，尽管有些工具会存在先天的性能问题，在多数情况下采用性能足够强劲的硬件便足以弥补（不幸的是这一点被一些缺德的供应商滥用了）。归根结底，我们建议你采用预算所能支持的最强劲的服务器、最快的存储，尽管最初会显得杀鸡用牛刀，但长期来看是划得来的。
构建的可扩展性又是另一码事。更多的产品意味着需要维护更多的构建配置、运行更多的构建（以及保存构建记录）。更大的代码量也意味着更长的构建时长。再者，为了获取更快速的反馈，用户需要更频繁的构建。因此挑战可拆分为三个方面：硬件（更多的构建服务器）、软件（一个健壮耐操、对用户友好的自动化构建系统）、以及构建本身的速度。
在硬件方面，我们需要大约十台新的构建服务器，而虚拟化技术在此派上用场了。与其采购并维护十台物理机，我们采购了一台性能特牛掰的服务器，配置了大量的高速存储，在上面部署了十台相同的虚拟机作为构建服务器。除了能够节省长期的硬件成本，我们还可以定期获取快照来便捷地管理构建环境。假如一次软件升级（甚至是一个用户）意外搞崩了构建环境，我们可以通过回滚到最近的快照来恢复。由此带来了下一条经验：
4.将构建环建纳入管控非常重要，特别是当你有多个构建服务器时。
更牛掰的硬件不足以显著降低构建时长。但拥有了多台牛掰的构建服务器后，我们可以执行并行的分布式构建（无论是通过编译器本身的特性还是第三方工具）。这是一项持续性的努力，时至今日我们仍在设法改善构建时长，例如通过降低代码间的依赖来提高构建的并行执行性。
在软件方面，我们弃用了那些老旧的、可读性差的构建脚本，取而代之的是我们自行开发的一个图形化界面的构建工具，利用该工具我们可以轻松地配置并运行定时构建，无需人工介入。我们还为一些开发人员提供了培训，使得开发人员没有配置管理团队的介入也能自行使用工具来执行各种构建任务。这些举措在当时而言已经足够了，而在今天看来我们所开发的工具是有其局限性的，该工具缺少一些开发成本高昂的特性，维护起来也耗时不菲。我们现在已经改用了第三方的持续集成工具。
在我看来，投资在自研的配置管理工具在长期来看是行不通的。我的结论是：
5.当组织规模还小时就开始采用现成的第三方工具。
尽量避免自行编写工具，因为最终你得不断迭代你的工具，重复去造那些第三方工具的轮子。
这些年来我们的开发流程也有了显著的改变。我们雇用了背景、经验不尽相同的开发人员，为此我们需要不断提高流程的健壮性，确保大家都能按正确的方式开展工作，同时也有利于更频繁、更快速的构建。
另一个显著改变的就是分支策略。当我们的规模还比较小时，几乎所有开发者都是直接将代码提交到活跃主干上。当采用了每日构建后，我们需要严格把控每一次的提交，否则构建将会一直失败。越多的开发人员也意味着非期望的变更越有可能引入到每次的构建中，有时甚至在产品发布后才被发现。而现在每个开发人员都工作在私有分支上，每个团队都有一个集成分支，只有当团队长评审过分支内容后才将其合并到主干。
有一个全新的需求就是要建立起变更项（缺陷或任务）、代码、构建这三者之间的可追溯性。当我们的规模还小时我们仅跟踪严重缺陷，开发人员自己记录在何时何处变更了什么内容，然后每一两个月构建一次。而现在我们拥有了超过一百名开发人员，每人每周负责处理若干个缺陷和任务，所有产品每天会构建多次。特性的交付，缺陷的修复，这些都不能再指望依靠开发人员来自行把控了。因此我敢说：
6.当开发人员超过一定数量时可追溯性是道必须要迈过去的坎。
我们设法将源码控制、问题跟踪、构建系统整合起来，结果就是当前我们每次代码提交都会关联上一个问题跟踪单，构建系统会将构建信息更新到对应的跟踪单上。我们还在尝试整合更多的内容，诸如需求和测试。
最后需要提及的一点是软件的成本。当用户量大时很多商业软件会贵得离谱，不仅仅是license，还包括管理成本、硬件配置以及其他乱七八糟的隐性成本。早前我们就决定替换掉我们的问题跟踪工具，纯粹就是因为license和维护成本远超其他同类型工具。几经评估过后我们发现了一个替代品，各方面比原有的工具更完善，成本还足足低了三十倍。由此得出的经验是：
7.持续评估评估你所使用的工具与市场上所提供的工具的成本对比情况。
我们也在评估是否需要替换掉我们当前所使用的、昂贵且略显过时的源码控制工具，毕竟这几年软件市场已经有了长足的发展了。
在一个成长中的公司负责配置管理的工作充满了挑战性，同时也很有意思。关键是要懂得提前规划。当你明确了目标和那些需要规避的坑后，你将更加游刃有余。
,
