增量升级这个名词相信已经不是什么新鲜事物了,甚至我们每天在不经意间也已经做了该事。比如windows的自动更新,就是增量更新的一种。先撇开系统软件的升级不说,作为一个业务应用开发者,笔者这里就自己所了解,介绍一下业务应用在做增量升级方面都采用哪些方法。
这个是最原始的增量升级方式,虽然简单,但繁琐且易漏易错,相信稍有点规模的应用都不会采用这种方式。想想如果有分布在不同子目录中的上百个文件被修改过了,你得执行拷贝覆盖多少次,更悲催的是,你花了九牛二虎之力才把文件拷贝好,结果却发现覆盖错了。
相对来说,使用rsync可以确保文件不会被误覆盖,也能保持目录结构的一致性。但个人觉得这只是一种文件同步,跟升级还是有一定的区别,如果我们的升级仅仅是涉及文件的覆盖或删除,或许采用rsync是一个不错的选择。但如果想在升级的同时自动执行某些定制的程序或脚本,那么rsync就显得有点爱莫能助了。另外rsync的引入,也需要额外的成本去搭建和监控它,自然也就需要额外的维护成本。而且rsync与版本库的无缝结合也是个值得考验的问题,能否由rsync直接从版本库中获取增量的部分,还是得额外写个脚本将增量部分写到rsync的同步目录中,再由rsync客户端来获取?
一般来说,采用这种方法,首先需要开发人员记录下哪些文件涉及改动,当然可通过查看版本历史的方式来判断哪些文件需要做更新;然后再针对这些文件,逐条编写相应的用于覆盖或删除线上应用的copy或rm语句;最后将包含这些语句的脚本随增量文件一起打包给运维人员,让运维人员到线上执行。从可靠性的方面考虑,这种方式还不如第二种方法,但相对来说,这种方式的可控性比较灵活,可以灵活自定义升级脚本,而不是简单的同步文件。比如可以定义在升级的同时执行某个特定的程序,最常见的就是在升级的同时重启原来的某些服务。
该方法是对方法三的一种增强,一方面是升级脚本是根据版本历史自动生成的,不再需要人工编写;另一方面,支持自定义升级扩展,也就说除了生成简单的增量覆盖升级脚本外,还支持以可插拔式的方式将自定制的程序让升级脚本自动执行。这是笔者选择的升级方法,也是本文的讲述重点。下面针对这种方法具体展开描述。
下面先从流程方面来大概介绍一下自动增量升级的整个思路,然后再从程序的角度解释一下本文中所涉及的脚本的作用。
升级流程分两个阶段,第一阶段为增量打包操作,一般由开发人员执行;第二阶段为升级操作,可由运维人员执行。
流程描述:更新版本库 ===> 生成增量清单文件 ===> 检查并修剪清单文件(以及编写自定义升级程序) ===> 生成增量补丁包
对应命令或脚本:svn update ===> gen_manifest.sh(需将结果重定向到PATCH_MANIFEST清单文件) ===> 添加或删除清单文件(PATCH_MANIFEST)中无需做更新的记录(同时根据需要编写想让升级程序自动执行的脚本,如demo_custom_script.sh) ===> gen_patch.sh
流程描述:获取增量包 ===> 执行升级操作并生成增量包的回滚备份包
对应命令或脚本:可通过wget获取增量包 ===> patch.sh(执行完后会生成增量回滚包,如patch_recover_20130626113450)
联系客服