版本的故事（一）为何要写版本的故事

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

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

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

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

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

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

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