DevOps企业实践指南(7): 版本管理

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

七个场景

我们列出实际项目实战中经常会碰到的一些典型场景，而这些跨项目的”反模式”是如此的熟悉，在我们实际的软件开发中真正实现了广泛地普及。
需要强调的是：版本管理一定要提前把其放到复杂的情况下进行考虑，才能真正地得出适合自己的最佳实践，几个人的小团队开发的几万行代码的功能单一的程序，一般来说碰到的问题都不多，但是同时考虑到多团队协作，多版本并行开发，多特性并行开发，紧急对应频发，例行部署众多，差分部署和回滚控制等诸多因素的时候，你会发现本来看起来无比简单的版本管理也突然不可思议地陌生和复杂起来。

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

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

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

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

• 随时：DevOps强调实现企业目标，无论是什么企业，业务的连续性的保持都非常的重要。如果在版本管理的这个环节不能做到随时保持一致，至少问题发生的时候的定位就会慢下很多。
• 代码：这里的代码值得是广义上的，不只是那些编译的源文件或者无需编译可以执行的代码文件，设定文件，以及一些设定的操作通过Infrastructure As Code的观点也需要进行版本管理起来，一切能够纳入版本管理的则需全部纳入。

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

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

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

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

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

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

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

项目规模小的时候，成员之间也相互熟悉，磨合的比较好了，当修改到可能会有影响的模块的时候，都会相互之间提示一下，即使不提示，通过持续集成的实践，也可以保证大部分时候持续集成这条流水线是通的，基本上不会造成太大的影响。这一切直到项目规模增大为止，同时加了三个不大不小的团队之后，一切开始变得混乱。
每个项目都朝那条线上进行持续集成，却不知道提交的代码会给别人带来了很多影响，尤其是共同模块的部分，简直是乱透了，最终变成了谁先修正就得按照谁的思路来，有的时候出现了冲突，干脆把共同拷贝一份自己管理起来，自己跟别人不再产生影响，唯一的代价就是代码的重复度高了一点，但是那又什么办法，并不是每个项目都能有很理想的架构和很理想的流程，而这一切都是他们那些新加进来的团队影响的，以前只有我们团队的时候，明明磨合的那么好。
总结一下这种场景：团队的规模对版本的复杂性会有一个很正向的叠加效应，大规模的开发会把原本很简单的事情变得很复杂，而这些更会引入更多的沟通和交流，消耗着团队原本就捉襟见肘的精力。

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

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

场景六：都是这个工具不好用

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

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

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

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

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

版本管理的七问

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

问题	内容
问题1	是否有一条基线能够随时保持和生产环境上使用的代码一致
问题2	是否有一条基线能够随时保证最新开发的内容可以随时进行发布
问题3	临时紧急线上修正能够减小对同时并行开发的团队的最小影响
问题4	多团队并行开发之间能否做到尽可能小的相互影响
问题5	发布是否能兼顾例行发布和紧急发布并能随时确认影响
问题6	团队是否熟悉版本管理工具并能在项目中有效使用
问题7	版本相关各操作是否有规范的流程以及忠实的执行

总结

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