持续集成之“软件自我识别”

winston

作者: 乔梁  来源: InfoQ  发布时间: 2012-01-07 15:33

　　在前文《自动化部署》中，我们讨论了自动化部署。通过对部署操作脚本化、部署验证自动化、部署环境版本控制、生产部署全自动化等诸多实践，可以让部署完全处于受控状态。然而，作为运维人员，是否曾经有人走过来问你这样的问题：“当前生产环境上部署的是哪个软件版本？”你是否遇到过这样的情形，即使手里拿着一个jar文件或dll文件，也无法知道它到底是哪个版本。也许你可能认为，这算不了什么，到某个管理平台上查一查部署记录就行了。可是，如果发现在生产环境的集群服务器上，不同机器上部署的同一个程序文件（比如.war文件）的大小却不相同，哪一个的大小是正确的呢？作为运维人员，你当时的心情会是什么样呢？

　　地点：运维人员办公室

　　下午五点钟，运维人员Steven习惯性地打开线上运维监控平台，一页一页地快速查看着监控数据。这已经成了他的一个工作习惯，只要有新版本上线，他总是经常打开监控页面看看。“好像没什么问题。”他暗自庆幸，“可以正点下班了”。

　　忽然，他的目光停在了一个流量曲线上。“为什么波动会这么大呢？”他又查看了其它几个相关曲线，没有什么问题，但直觉告诉它，可能新版本部署有问题。于是，他开始了更详细的跟踪分析。

　　时间随着电子表的跳动，一分钟一分钟的过去了。终于，Steven站了起来，深深地吸了一口气。此时，时钟已指向晚上八点啦。他发现，在生产环境的集群中，有五台机器的应用程序文件包与其它机器上的文件包相比，文件大小不一样。到底哪个是正确的呢？

　　Steven首先查了一下部署管理日志系统，文件名为abc，正确版本是1.21。可是这两种文件的文件名都是abc.war。从文件名上没有什么区别。无奈，Steven操起电话，把开发人员Bob从家中叫了回来，一起解决这个问题。

　　又经过三个多小时的忙活，两个人终于找到了正确的版本。原来，只有那五台机器上的二进制包是正确的，其它机器上的都不对。这两个版本都属于1.21，只不过，其中一个是快上线前修复bug的一个测试版本，而另一个是正式上线版本。它们在版本库中的revision只差一个。可能是谁部署时不小心搞错了。

　　地点：开发团队工作室

　　第二天一大早，Steven在站会上把这个Case通报了一下，引起了Joe的注意。Joe说道：“我们站会之后讨论一下，怎么避免这类问题的发生吧。”

　　于是，站会后，Joe、Bob、Alice和Steven在一个角落里坐了下来，并叫来了运维主管Tom。

　　“我们都使用了自动化部署，怎么还会出现这个问题呢？”Tom不解的问道。

　　Steven答道：“我查看了一下脚本，这部分没有做验证，我今天把它加上。不过，这两个版本的文件名称是一样的，只能在部署前拿到它们的MD5，进行比对验证。”

　　Alice说道：“我们还可以对文件名进行规范，在文件名上加入版本号，比如appname-xxx_xxx。”

　　“这也是解决问题的一个办法。但是，你知道，文件是很容易被重命名的。”Joe说道。

　　Tom又说道：“我们可以把MD5和一些元数据信息，比如revision等放到一个无数据描述文件中，并打包在应用程序中。比如，在Java领域，所有的.jar, .war 和.ear文件都允许将这些信息放在META-INF/MANIFEST.MF文件中。”

　　“嗯，这也是种好办法。但是，如果能让应用程序自我识别，不是更加直接吗？”Joe说道。

　　大家一脸迷惑地看着Joe，不明白他在说什么。

　　“我们让应用程序告诉我们它是什么版本，不就是自我识别嘛！”Joe笑道，“其实，这也不是什么新鲜技术，你们一看就明白了。”

　　Joe打开笔记本，接上了21寸的显示器，把他们使用的持续集成和发布管理工具Cruise的界面打开了，如图1所示。

图1 软件自我识别版本信息

　　接着说道：“这是我们用的Cruise服务器的信息页面。从这里，我们可以很清楚地看到这个应用程序的运行环境信息，比如Java虚拟机的版本、操作系统类型与版本、服务器存储空间信息、应用程序的数据库版本、license信息等等。更重要的是第一行的服务器版本信息。(1)表示其对外发布的版本号；(2)和(3)可能对应着其revision号。”

　　“我从来没有看过这个页面。”Bob和Alice同时说道。

　　“这里面的信息很多啊。”Steven有点儿兴奋的说道，“如果我们的应用程序也可以这么做的话，我在这方面的运维工作会轻松很多，因为我可以把自动化部署脚本和自动化部署验证做得更强大一些。”

　　Alice说道：“我们的很多组件都以库文件方式存在，没有界面，那怎么办？”

　　“没有关系，”Steven说道：“界面对自动化运维来说是次重点，最重要的是可以通过一些API以命令行的方式来执行。”

　　Joe点头说道：“让我们来总结一下吧，看看接下来做什么。”

　　应用程序自识别的应用场景与实现方式

• 可以直接拿到应用程序安装文件或二进制包时
  从它的元描述文件（metaData）中查看它来自于哪里。大多数现代二进制格式支持以某种方式做到这一点。比如，你使用Java时，所有的.jar, .war 和.ear文件都允许将这些信息放在META-INF/MANIFEST.MF文件中。如果你是在Windows上，创造性地使用versioninfo resources也能达到同样的效果。注意：并不是说把这些信息放在文件名中，因为修改文件名的可能性很大。
  
• 当你无法拿到正在提供服务的二进制文件时（比如应用程序是一个远端服务，无法直接登录到服务器上）
  最容易的方法是能够访问一个已知的URL或者服务调用API，它能够告诉你任何你想知道的信息。到底是什么样的UR或服务调用并不重要，只要需要知道这些信息的人知道怎么调用它就行了。
  

　　当然，API方式还有更多的用途。

　　比如，当你使用持续部署实践时，你在部署之前可以验证一下将要部署的二进制是不是正确的版本。

　　然后，你可以在部署之后，使用这个服务调用去验证应用程序的正确版本是不是启动并运行了。

　　如果有一个动态更新的系统信息显示板，你就可以快速且方便地看到哪个软件安装的是哪个版本，而不用去更新文档，因为文档很容易忘记更新。

　　最后，Steven和开发团队一起，商定了一些细节。

• 每个组件的文件名按照如下格式生成：组件名+对外版本号+版本库revision号。
  
• 每次构建中生成该文件的MD5码。
  
• 在打包时，将这些元数据信息写入元数据描述文件。由于使用subversion版本控制库，而且，各组件的代码库会做迁移，所以元数据中，至少包含该构建版本对应的源代码svn库的URL和revision。
  
• 每个组件都提供统一的API调用whoami，要求返回形如NAME0-PUBLIC VERSION:svn URL@revision的自识别信息。
  
• Steven根据上述信息，更新部署脚本，以及自动化部署验证测试。
  

相关文章：
持续集成之戏说Check-in Dance
持续集成之“软件自我识别”
持续集成之“自动化部署”
持续集成之“依赖管理”
持续集成之“分支策略”(续)
持续集成之“分支策略”​
持续集成之“测试三角形与分段构建策略原则”
持续集成之“Everything is code”
持续集成之“自动化部署”