在推行DevOps的过程当中，持续集成和持续部署都是DevOps落地时须要重视的重要基石。而最终保证DevOps成功实施则须要更多更加细致的细节落到实处，好比版本管理。在这篇文章中咱们将会结合企业实施版本管理中常常会出现的七个场景去理解为何版本管理是复杂的，在此基础上提出”版本管理的七问”用以对帮助企业对自身版本管理能力进行快速的定位，同时在此基础上进行适合本身的最佳实践探索。git

七个场景

咱们列出实际项目实战中常常会碰到的一些典型场景，而这些跨项目的”反模式”是如此的熟悉，在咱们实际的软件开发中真正实现了普遍地普及。
须要强调的是：版本管理必定要提早把其放到复杂的状况下进行考虑，才能真正地得出适合本身的最佳实践，几我的的小团队开发的几万行代码的功能单一的程序，通常来讲碰到的问题都很少，可是同时考虑到多团队协做，多版本并行开发，多特性并行开发，紧急对应频发，例行部署众多，差分部署和回滚控制等诸多因素的时候，你会发现原本看起来无比简单的版本管理也忽然难以想象地陌生和复杂起来。web

场景一：在我本地机器是好用的

生产环境出了问题，确认以后，没有能发现问题所在，由于在开发者的本地环境是能正常运行的，并且在公用的测试环境中也不能再现，因而这类问题起初被定为成”只有生产环境才会出现的奇怪问题”。
确实存在此类问题，尤为是那种早期动辄百万和千万行的的大型系统，谁也不敢随意触碰。可是有不少这样的问题在最后缘由分析的时候却发现仅仅是因为版本的不一致性致使的：生产环境和测试环境的不一致性，而这种不一致性又没有获得很好的管理，因此出现了这样的问题。具体举例来讲：数据库

• 生产环境使用的是数据库的RAC环境，而因为License的缘故，测试环境基本上都使用普通的Database的实例
• 生产环境使用的存储，而测试环境用的就是本地的磁盘
• 生产环境的数据库和其余软件安装以后，设定内容众多，很难保证全部的设定都一致
• 大型的系统有可能几千个文件须要部署的复杂状况，多人共用的测试环境缺少机制保证这些文件和版本管理的某条基线都一致，即便是我的独占的环境，保证此环境中的几千个文件和生产环境如出一辙，很少很多，也不是一件容易的事情。
• …

总结一下这种场景：在版本管理中须要有这样一条基线，可以随时保持和生产环境上使用的代码一致。这里注意如下要点：安全

• 随时：DevOps强调实现企业目标，不管是什么企业，业务的连续性的保持都很是的重要。若是在版本管理的这个环节不能作到随时保持一致，至少问题发生的时候的定位就会慢下不少。

• 代码：这里的代码值得是广义上的，不仅是那些编译的源文件或者无需编译能够执行的代码文件，设定文件，以及一些设定的操做经过Infrastructure As Code的观点也须要进行版本管理起来，一切可以归入版本管理的则需所有归入。

  场景二：这不是正确的发布版本

  大部分的项目除了最初一次新版本的发布时是从零到有的过程，剩余的状况都是从”旧有”到”新有”的过程，在进行既有功能的维护的同时也有新功能的增长。
  从Agile到DevOps，打通的不只仅是那一堵墙，打通的更是价值流动的最后一千米。可是没有版本管理良好的控制，试想一下，只须要是以下场景就变得很是的复杂：架构

• 通常性缺陷的修复

• 紧急故障的修复
• 多团队多特性并行开发

这些修复的内容做为可以交付的价值只有在生产环境上实际的进行运行，才能为客户提供价值，才使得Agile的开发交付的成果有了意义。这些修复之间每每依赖复杂，因为这些依赖咱们不得不调整发布的顺序，否则轻者一些会使得须要发布的内容没能发布，重者会使得已经修好的缺陷再次出现。
总结一下这种场景，一条基线可以随时保证最新开发的内容能够随时进行发布，这件事情也很是重要。svg

场景三：都是紧急对应惹的祸

项目的管理一切都在层次分明地进行着，直到连续出现的紧急对应。紧急对应以后，忽然发现一切都乱了，原本例行的测试完毕的内容只须要合并到Trunk上就行了，如今须要把紧急发布的部分也合并进去并进行测试，这么多rework，紧急对应出一次合并一次追加测试一次，弄得乱糟糟的，最惧怕的是万一合并漏一个质量就倒退了，明明已经上线过的紧急对应，在此次例行的发布以后又很差用了那就是大事件了。多团队有依赖时就会更加复杂。
总结一下这种场景：临时紧急线上修正可能会对同时并行开发的团队产生不少影响，同时例行的发布也能会所以受到调整，必须总体考虑妥善的开发和发布流程。svn

场景四：都是他们团队影响的

项目规模小的时候，成员之间也相互熟悉，磨合的比较好了，当修改到可能会有影响的模块的时候，都会相互之间提示一下，即便不提示，经过持续集成的实践，也能够保证大部分时候持续集成这条流水线是通的，基本上不会形成太大的影响。这一切直到项目规模增大为止，同时加了三个不大不小的团队以后，一切开始变得混乱。
每一个项目都朝那条线上进行持续集成，殊不知道提交的代码会给别人带来了不少影响，尤为是共同模块的部分，简直是乱透了，最终变成了谁先修正就得按照谁的思路来，有的时候出现了冲突，干脆把共同拷贝一份本身管理起来，本身跟别人再也不产生影响，惟一的代价就是代码的重复度高了一点，可是那又什么办法，并非每一个项目都能有很理想的架构和很理想的流程，而这一切都是他们那些新加进来的团队影响的，之前只有咱们团队的时候，明明磨合的那么好。

总结一下这种场景：团队的规模对版本的复杂性会有一个很正向的叠加效应，大规模的开发会把本来很简单的事情变得很复杂，而这些更会引入更多的沟通和交流，消耗着团队本来就捉襟见肘的精力。工具

场景五：例行发布不能正常实施了

每月进行一次到两次例行发布，会将按照计划规划的特性或者缺陷的修正发布到生产环境之上。可是项目规模的扩大以及应用的不稳定致使了不少问题的出现。应用的不稳定致使了不少缺陷的出现，这其中有些是很是紧急的须要当即修复的，确定来不及在例行的发布中进行解决。而这些紧急的对应跟接下来的例行发布每每有着依赖关系，甚至有的时候就是同一个文件，这些必然会致使例行的发布进行从新排序或者合并和追加测试等操做。
在原本例行发布就不少的状况下，加之紧急对应又有不少，忙中出错，管理漏了一两个也是偶尔会发生的事情，好比忘记合并紧急发布的内容到接下来的例行发布中，致使对应完成的故障从新出现，也致使了质量的倒退。
总结一下这种场景：兼顾例行发布和紧急发布并能保证在规模化的开发时也能保证质量，这样的规范流程对版本管理很是重要。学习

场景六：都是这个工具很差用

如今的版本管理工具多种多样，开源的，闭源的，收费的，免费的，甚至不少企业自行开发了一些适合本身用的工具以提升效率。今天用这个，明天用那个，这个尚未熟悉就改换另一种，不少时间用来学习这些工具的使用，在本来都不太宽裕的开发进度下，偶会会出现由于工具的使用不够熟悉致使的各类问题：什么没有提交到仓库，git commit以后还要push麽，不是跟svn commit同样麽，svn我就是这样用的没有问题啊。Merge时提示的信息没有看明白，致使把别人对同一个文件的修正给覆盖了，这主要是怪工具，我之前用熟悉的工具的时候就没有这个问题。诸如此类的问题每每对一些新手或者刚刚使用一些新的版本管理工具而事前没有足够时间去培训的状况下屡屡发生。
总结一下这种场景：工具很重要，可是它只是咱们实现目标的助力之一，团队熟悉版本管理工具并能有效利用对总体的开发效率很重要，同时会大大下降版本管理出现的问题。测试

场景七：我没有仔细地看那个上线以前的版本差分

在进行到持续部署的最后环节，不少企业本来能够进行全自动的流程特地改为了半自动，会加入一些进行检查的流程实践，好比会本着谁修改谁提交的原则，则是为了上线以前的一道护身符，每每会确认一下等诸多信息：

• 发布的文件个数够不够
• 发布的文件的版本对不对
• 发布的文件的修改内容是否是你修改的内容，有没有别人提交的内容被混进去
• …

这不是为了要作一个反模式，特地推荐手动做业，在推行DevOps的时候不能教条化，全自动是好的，但全自动是须要有”安全带”的，而这个安全带每每因为成本太高和执行的信念不够强而不少时候形同虚设。只须要项目紧急一点，这个安全带是不会有的，而项目都是紧急的，成本都是不够的，这就是现状。因此在经过持续改善实现最终目标以前这些规范的流程仍是必需要进行严格执行的。否则把尚未通过彻底测试的别人的内容带出去了，或者debug的模式没有关等等状况都会出现，而这些原本是经过上线以前的版本差分确认等例行确认操做就可大大下降甚至避免的简单问题。
总结一下这种场景：版本管理须要规范和完善的流程，更须要严格忠实的执行。

版本管理的七问

针对这七种场景，如下列出七个问题，经过不断对这个七个问题进行自查，企业即可以简单了解到本身目前版本管理的水平和前进的方向，以便进行持续改进。

总结

版本管理这七个场景并不能涵括全部模式，而七问也没有所谓的标准答案。可是这些场景确实是项目实践中很是典型的总结和整理，经过对这些场景进行反思，综合考虑多团队协做/多特性并行开发/紧急对应/例行发布等诸多因素，保证规模化的开发在复杂的环境下也能顺畅实施，则能实践出一条属于企业本身的完善的版本管理之路。