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

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

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