随着组织的发展，开发人员越来越多，很多公司开始建立专门的技术部门开发共用组件。能不能做出好用的共用组件，技术能力当然是必不可少的。但是经历了很多项目的生生死死，越来越觉得版本管理也是一个十分重要的因素。很多基础组件做的时候红红火火，做了两年就恍恍惚惚了。有很多老的版本漂流在外，新的项目和老的项目开始出现依赖冲突，现场部署不下去了。询问组件的开发者哪个版本能用，也给不出一个确切的答复，只好“全部升级最新版本”。共用组件生存在调用链的最低层，全部升级涉及多少产品，开发工作量运维工作量多么的巨大。

于是一些团队不得已把这些共用组件源码拿过来，搞个目录自己管了，从此分道扬镳，再不用标准版了。两年过去，新人成为老人，铁打的公司流水的团队人员来了又走，只留下一堆代码仓库和外面好多不知道来历的二进制包。哪个项目组要是使用了这些祖传组件，开发的人都头疼。明明是一件好事，却做成了这个样子。

但是共用需求毕竟存在，每隔两年又会有一批新人雄心勃勃的开始下一个新的共用组件。于是一代代循环下去，每一代人都做不长、做不大。我们一次一次的搭建二层小楼，却建不起来高楼大厦。

这就是我为什么要写版本的故事。开发大型软件一定要解决跨时空、跨团队的信息沟通问题。“版本”是一个非常重要的信息，它标志了软件产品的型号。如果研发团队没有把版本管好，很可能导致多年之后、另一个工序产生麻烦，产生诸如：“某个二进制包找不到代码基线，所以无法修复这个缺陷”、“某个产品版本搞不清依赖关系，不好升级部署”，此类问题。这件事情是为未来打算、为他人打算，所以经常得不到重视。

技术固然重要，没有技术，产品做不出来，做出来跑的不快。但是版本管的不好麻烦也很大。就好比一家工厂，设计人员和技术工人肯定是非常重要的，但是如果不在设计图纸和零部件包装盒贴上型号标签（这个型号标签就等同于软件的版本号），以至于设计师经常找不到某个型号的图纸在哪里，生产线上出了缺陷也无法判断影响哪些批次的零件，生产过程就容易出现返工和浪费，也很难生产出复杂的产品。

版本管理对技术发展也有很大的促进作用。跟踪和记录组件版本可以帮助我们理清产品的依赖关系，比如“某个组件在哪些产品中使用，如果我们不再维护这个组件的 1.x 版本会影响哪些产品”、“某个产品从什么版本开始引入了某项技术，在哪些环境中部署过”。这些信息对技术演进有非常重要的作用。如果没有这些数据，我们就无法判断技术升级的影响范围。一处更改会造成大范围的错误，于是只能放弃升级，产品被锁死在陈旧的技术上。行业在变，产品年年不变，限制企业的技术竞争力。

这是一个系列的写作，我会结合代码管理、构建管理、集成测试、产品发布、部署这些过程，详细说明版本管理过程。一个组件、一个产品应该怎样编制版本号，把这个版本号烙印在二进制包里，在开发、测试、发布的过程中管理某个版本的状态。最后部署这个软件的时候，怎样分析依赖关系，找到合适的版本。六个月之后，当产品经理要求在某个老版本上更新一个功能的时候，应该怎样做。