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

　　在前文《自动化部署》中，我们讨论了自动化部署。通过对部署操作脚本化、部署验证自动化、部署环境版本控制、生产部署全自动化等诸多实践，可以让部署完全处于受控状态。然而，作为运维人员，是否曾经有人走过来问你这样的问题：“当前生产环境上部署的是哪个软件版本?”你是否遇到过这样的情形，即使手里拿着一个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方式还有更多的用途。

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

原文转自：http://kb.cnblogs.com/page/127845/