本节书摘来自异步社区《配置管理最佳实践》一书中的第1章，第1.6节，作者： 【美】Bob Aiello , Leslie Sachs著，更多章节内容可以访问云栖社区“异步社区”公众号查看

1.6 工具的选择

在实施任何一个源代码管理解决方案中，工具的选择都是一项非常重要的任务。选择一个源代码管理工具需要考虑众多的因素。针对这一主题，我会在这章只讨论最基本的方面，而在我们的网站上（www.cmbestpractices.com/tools）专门讲了一个工具的选择部分作为对本章的补充。这样一来，就可以保证内容的时效性，同时可以允许我的同事说出他们的观点，尽管很多时候这个题目都会变成激烈的宗教般的争论。

首先可以观察到的一个事实是，目前市场上有众多优秀的源代码管理工具。感谢厂商们开发了如此众多商业的和开源的优秀源代码解决方案。我的经验是，所有的工具供应商都值得赞誉，因为他们不仅仅关注短期的销售产品的目标，还关注开发和传承高效的最佳实践。即便是一些“不好”的工具在某些特定的情况下都有它们的地位。最重要的事情是开始评估自己的源代码管理解决方案的需求，然后以开放和务实的态度去评估哪些解决方案最符合团队正在做的工作。所有的源代码管理工具都是不一样的，也就造成了某些工具在某个特定项目中可能会表现得好些或者坏些。一些工具的功能不是很丰富，可集成到一起的其他工具也不是很多；而另外一些可能学习曲线很陡峭，可一旦用户接受了全面培训和得到支持，工具就会体现出巨大价值。

许多常用的源代码管理工具最大的问题是缺乏测试和控制代码库自身内部完整性的能力。例如，我就看到过在一些非常著名的源代码管理工具中，代码没有任何迹象就直接丢失了。在工作过的某大型金融服务机构中就发生过这类问题，代码丢失导致公司蒙受了重大损失。

在开源软件和一些大型知名厂商的商业软件中，都出现过类似的问题。因此，把金融交易系统的源代码放在这样的工具中也许不是一个万无一失的方法。最好的方法是，保留额外一份代码的备份，以便用来构建和发布产品。

下面是在选择源代码管理解决方案时应该考虑的方面：

• 容易使用（相对于学习曲线来说）
• 具有分支的能力
• 代码合并（图形界面和命令行都支持）
• 变更历史
• 建立基线（例如标记和标签）
• 变更集
• 管理工具（例如可检查代码库的完整性）
• 成本（包括总拥有成本）
• 有效的培训和支持
• 与常见IDE 的集成
• 完整的 ALM解决方案（相对于与第三方工具的集成）
• 良好定义的使用模式
• 开源软件与商业软件
• 产品成熟度
• 供应商承诺
• 可扩展性和开放的API
• 实施的时间和成功的风险

一开始最重要的是定义选择有效配置管理解决方案的目标。然后，通过上面提到的和其他未提到的方面来选择合适的源代码管理解决方案。有时候基于仅仅一项或者多项标准就可以排除某个工具。例如，很多公司的开发团队非常大（数百名到千名）分布在全球各地，包括美国、欧洲和亚洲各地。在这种情况下，源代码管理工具真正显示出了其价值所在，因为它可以帮助保护代码、组织开发工作，并且可以知道团队每天都在做什么。有时，当团队真正需要更强大的工具提供某些高级功能的时候，就需要提前规划好必要的培训和支持。在某些公司，需要在同一代码库中支持多个变体，这就要求工具必须支持复杂分支和代码合并。

随着更改的增多，查看所有更改的历史记录很快就会变得很复杂。大多数公司都需要能够很容易地查看这些历史记录的功能。所有的开发团队都要有建立基线的能力。在某些有IT控制和法律合规监管的公司，这是一项基本的要求；相反，在我读研究生做课后作业时，建立可靠基线就不是那么重要了（虽然那时我也使用源代码管理工具）。例如，如果期望一组确定的变更可以很容易地应用到（此分支）或者回滚时，那么变更集是非常有用的，哪怕这仅仅影响到你是否可以按时交付作业。许多组织也非常看重是否有一个可靠的供应商或者开源社区支持这个工具。

1.6.1 开源软件与商业软件
在选择工具的时候，我们还应该考虑公司在开源和商业配置管理工具上是否有强烈的偏好。哪一种类型的工具都有优点和缺点。一些开发人员认为开源软件好，因为源代码是可见的，而且有活跃的用户社区在开发更多的功能；而商业软件的拥护者则认为商业软件的支持和功能更好些，因为有一个很大的专职研发团队在开发这个软件，通常这意味着可以从一个技术一流的公司得到支持。还有一种结合了上面两种方法的情况，即商业软件供应商愿意对所有人公开自己的源代码，并且允许他人可以通过定义好的API写代码来拓展功能。另外一种很流行的做法是提供一个免费的（或者不受任何限制的评估用）版本，其中某些功能或者许可证的数量是有限的。选择商业或者开源代码管理解决方案是一个非常有趣且很热门的讨论，双方的很多看法都很有道理。针对这一点，在这本书的支持网站上有很多更深入的探讨（www.cmbestpractices.com/tools）。尽管如此，我们还是要考虑公司对开源或者商业工具是否有某些强烈的偏好，公司里的采购部门是否把它当作选择工具的标准之一。

1.6.2 产品成熟度和供应商承诺
我曾经使用过很多在短期内几乎很少有大改进的十分成熟的产品，既包括开源的也包括商业的。我也使用过很多采用了尖端技术的工具。工具太新了，以至于都没有一个明确的安装说明文档。成熟的产品中，很少会遇到难题和使用问题，但是这些工具往往具备的高级功能也少，无法极大地提高程序员的工作效率。有时我们想提高工作效率但又不想在源代码管理中太冒险，这时就需要在软件成熟度与使用产品风险间取得平衡。在采用最新最好的源代码管理工具集之前，一定要确认供应商已经做好准备，能够且愿意给你提供支持去维护这套先进的源代码解决方案。

1.6.3 可扩展性和开放的API
当有同事想通过开放的API或者 shell 脚本去扩展或者修改源代码管理工具时，我一般都劝他们不要着急，想好了再做。虽然使用脚本（例如触发器）可以有助于强化流程，但是支持定制工具花费的时间和精力也是必须要考虑的。我看到很多写脚本或者封装工具的工作最后都惨败了。通常最好是与供应商合作，制定出一个好的解决方案，然后和整个用户社区共享。起初虽然没发现自己写的脚本有什么问题，但是当开源社区使用并且给你提出很多意见和建议后，这些脚本就会变得更加可靠。如果你是唯一一个知道这些脚本如何工作的人，这对于你和你的公司都不是一件好事。

1.6.4 不要过度工程化源代码管理
在配置管理中，我看到的最大的错误就是开发人员用心良苦过度地工程化源代码管理工具。源代码管理工具有许多很酷的特性，很多技术人员一看见就感到兴奋，于是一旦开始工作就尝试去自动化一切。有的时候，这会导致源代码管理方案加进去很多花里胡哨的东西，导致整个系统常常无法正常工作。如果整个系统因为那些花里胡哨的东西而无法工作恰巧发生在负责的技术人员度假时，就会给公司造成很大的麻烦。把过程自动化，集成到源代码管理工具中是不错的想法，但这应该仅限于在自动化完成这项任务的情况下，不要添加更多其他的东西。源代码管理解决方案应该体现敏捷和精益的原则，从而达到更好的效果。

例如，创建一个分支来支持一个缺陷修复是一个很不错的想法，但是如果针对每个缺陷都要创建一个单独的分支就会太复杂。实际上没有什么不可以违背的原则，但还是建议尽量保持你的流程精益，仅仅自动化那些十分必要的部分。

另外一个常见的错误是很多人写脚本会在源代码管理工具命令行外再封装一层。这种做法的错误就在于用户通常都不知道这个工具正在做什么。因为脚本隐藏了工具的功能，常常替代了实际的培训和清晰的流程。如果真的要写脚本自动化源代码管理工具，我建议脚本要清晰地显示出每个执行的命令和命令的输出情况，这样就不会隐藏源代码管理工具的实际操作。这样的做法可以让你清楚地知道脚本做了什么，也有利于工具的培训。对于成功地实施任何源代码管理工具和能自动重复地执行任务的脚本，培训都是最关键的因素。一定要确保能够为团队提供足够的培训，使他们了解如何充分利用配置管理工具。脚本不应该替代培训，更不应该隐藏工具的功能。当脚本隐藏了工具的功能，开发人员就无法了解如何使用源代码管理工具最基本的功能，而这常常会导致错误和降低工作效率；同时，还要有人维护和升级脚本，这通常是件耗时且易出错的活儿，无论对于个人还是开发团队都不是件好事。选择合适的工具，使用模型和过程很重要，培训则更重要。同样重要的还有考虑影响交付优质产品的各个方面，包括质量成本。