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

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

乔梁 有十多年软件开发及项目管理经验,专注于提高软件企业提高交付能力。现任百度项目管理部高级架构师。

This entry was posted in Agile, Best Practices. Bookmark the permalink.

发表评论

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / 更改 )

Twitter picture

You are commenting using your Twitter account. Log Out / 更改 )

Facebook photo

You are commenting using your Facebook account. Log Out / 更改 )

Google+ photo

You are commenting using your Google+ account. Log Out / 更改 )

Connecting to %s