俗话说有人的地方就有江湖，有开发人员的地方就会用到版本控制工具，这已经成为了业界共识，版本控制是团队协作的基础。当企业规模较小时，一般使用一些开源的版本控制工具，比如Git、SVN等。由于这个时候客户规模较小，数据量不大，业务也比较单一，开源的版本控制工具能够基本满足需求。但随着企业规模的扩大，数据量和用户都随之增长，业务也更加复杂，版本控制工具就会面临一系列的挑战。首先是分支管理的难度增加。通常来说，我们使用的分支类型有主分支、开发分支以及发布分支等。如果有多个功能在并行开发，就会拉出很多功能分支，到项目开发的后期，一个项目就可能有几十个分支。维护这些分支间的关系会变得非常复杂，如果只用命名的方式进行区别，而没有一个图形化的界面去展示分支关系，可能会随着时间推移而忘记分支间的关系。另外，分支合并也成为一个难题。目前市场上的一些版本控制工具，分支合并能力很弱。大家可能都有类似经历，在分支合并时，会引入一系列不必要的冲突，需要人工去解决。往往一个发布周期的前几天都是在解决这些冲突。第二个挑战是数据量过大。龙智的一些客户后期数据量达到几十、上百T。数据量达到这个级别，面临的问题就是数据提交速度会非常慢，例如一些10G以上的大文件，提交速度非常缓慢，并且经常提交失败。数据量过大还会导致存储问题。单个库是无法承受如此之大的数据量的，只能将数据进行拆分，再放到各个系统中，这导致了后期维护的成本成倍增加。到了开发后期，可追溯性也成为一个问题，因为数据分散在不同的系统中。面临的第三个挑战是跨地域协作。企业规模扩大后，项目组成员分布在全国甚至全球各地的情况。在这种情况下，面临最明显的问题就是跨地域提交。因为带宽或网络波动，可能会造成提交延时或失败。第四个挑战来自于安全及审计需求。开源版本控制工具的权限控制能力较弱，比如Git的权限控制是到项目级别，SVN是到文件夹级别。在项目中，难免有一些重要文件需要进行严格的访问权限控制，这样就需要版本控制系统的权限控制力度细化到文件级别。并且，如果在审计方面没有完备的日志，后期定位、追溯问题都会十分麻烦。当企业面临的问题越来越多时，其实是在释放一个信号：目前所使用的版本控制工具已经无法满足企业的业务需求了。同时，也会发现工作效率在下降、管理成本增加。虽然在版本控制工具上节省了开支，但无论是成本管理还是工作效益，都造成了很大的损失，这是隐性的成本。所以，此时要改变观念，把版本控制工具放在更重要的位置，需要为企业寻找一款更高效、更安全的版本控制工具。强壮的版本控制系统是研发流程的核心。为什么这样说？企业，特别是软件企业，大部分的劳动成果（比如设计资料、代码、配置项、生成物等）最终都会转换成数字资产，而这些都投入了大量时间和资金，所以数字资产很重要。其次，所有的研发工作都是围绕着数字资产展开的。作为管理这些资产的版本控制工具，更是处于研发流程核心位置。它为团队围绕数字资产展开的工作保驾护航。一款好的版本控制系统可以在单一的平台上安全、高速地管理您的一切数字资产，无论资产的类型、位置、大小以及体量。那么，如何评判一款版本控制工具是强壮的？我认为可以从以下几个方面来考虑。首先是性能。简单列举一下，第一点，需要有很好的伸缩性。当企业规模只有几十名用户时，使用都很方便。但企业规模扩大，就需要版本控制系统能够支撑上万名用户。或是当数据量增加到几百T的时候，版本控制系统需要实现平滑的升级。第二点，对于全球团队合作的情况，则要求版本控制系统是灵活的分布式部署，以满足团队间的高效协作需求。第三点，需要支撑每天数以千计的流水线构建。企业每天可能有成百上千的流水线在构建，对于版本控制系统的性能来说也是一个挑战。第四点，现在的企业很多依赖于使用Git的开源项目，那么，版本控制系统需要提供一种可能性，既能兼容前端的开源工具，又能通过版本控制系统强大的后台为后端提供支撑。最后，是统一的企业级灾备计划。备份需要能够轻松维护，一旦发现问题事故，也能快速恢复，最大程度降低企业的损失。然后是安全。版本控制系统需要有非常灵活、强大的权限控制机制，能够在文件级别进行版本控制。并且需要非常灵活，能够通过组的方式将权限下放给真正了解项目的人。审计方面需要有完备的记录，谁修改、谁访问、何时修改、何时访问等都需要记录在册，这是后期审计的基础。最后是界面友好。版本控制系统需要与DevOps生命周期中各个环节的工具进行良好地集成，例如IDE工具、代码评审工具、需求管理工具以及后期的流水线集成。集成后即可推动DevOps的各个环节，加速产品迭代。
