发布管理原则

发布管理原则

－ 把构建产物进行打包、形成一个可发布的版本

－ 用一个不可变、易识别的 ID 标识可发布版本

－ 自动化打包、标识可发布版本的过程

－ 发布管理的过程要快速、可靠

－ 有快速核实可发布版本唯一性的机制

－ 存档可发布版本、提供回溯和审查

InstallShield安装包工具

用一个不可变、易识别的 ID 标识可发布版本

可发布版本的标识不可变且易识别很重要。易识别是只说的时候好指代，看的时候还分辨。比如如下几种标识，大家一眼就能看出各自的优劣。

eclipse-inst-mac64.tar.gz

jdk-8u131-linux-x64.rpm

VirtualBox-5.1.18-114002-OSX.dmg

bugzilla-2.18.1.tar

CentOS-7-x86_64-DVD-1511.iso

Skype_7.39.176.dmg

YoudaoNote.dmg

QQ_V5.2.0.dmg

DingTalk_v3.3.0.dmg

sogou_mac_40g.dmg

随便翻了下我的下载目录，贴出了10个软件的安装包。大家觉得哪个一眼看上去就能记住，哪些容易描述给其他人听？

一个容易让人识别的可发布版本的包，应该包含以下几个方面：

软件／产品名称：告诉大家这是什么

版本号：要有个递增的顺序，三位命名法还是四位命名法无所谓，但至少让人知道高版本是最新发布的版本，拥有更多的功能。

平台：这个包是可以装到 windows 上，还是可以装到 Mac 上，还是Windows/Linux/Mac 三平台通吃。

架构：是64位的系统，还是32位，还是不限

格式：也就是说这个包要用什么程序去处理。比如 rpm 的包，直接用rpm 安装；dmg 双击，tar.gz的包要先解压缩，而ISO的需要弄个虚拟光驱。

其它辅助信息：有的产品会在正式版发布之前把一些 RC 的包发布出来，收集反馈和让大家尝鲜，看看是否有大bug，同时也让大家有个心理预期；有的产品愿意把时间戳也放到包名字上；有的包会把这个版本的项目名字也带上，比如eclipse 4.4 项目代号是 luna，这个版本的Linux 32bit发布版本是eclipse-java-luna-SR2-linux-gtk.tar.gz；4.5的项目代号是mars，这个版本Windows平台的正式发布版本是 eclipse-jee-mars-2-win32-x86_64.zip

可发布版本的标识不能变化。这是因为一旦标识变化了，大家指代上就会出现问题。比如 eclipse-jee-mars-2-win32-x86_64.zip 和 eclipse-jee-4.5-2-win32-x86_64.zip。任何一个人看到这两个包估计都会懵。一开始可能还记得这是同一个包，但是过一段时间可能谁也不知道这俩包到底是啥关系了。

自动化打包、标识可发布版本的过程

把可发布版本的标识说清楚之后，就要把打包、标识的过程固化下来。怎么做呢？自动化这个过程，每次都按照同一个流程，使用同一个办法去打包，去标识它。

发布管理的过程要快速、可靠、可重复

本来就是个简单的过程，就不要弄的那么麻烦。能快速、可靠、可重复的实现这一过程就好。

有快速核实可发布版本唯一性的机制

每个包都要算个md5 吧，SHA1也可以。至少有其中一个只，就能知道这个包是不是它名字标识的那样。

存档可发布版本、提供回溯和审查

所有有意义的版本都要存档以便于回溯和审查。互联网行业最关注的是上个线上版本、线上版本和当前版本。一旦线上服务器故障，还可以用当前线上版本部署一台新的机器出来；如果当前版本引入了个大bug，暂时会推到上个版本也许是最好的选择。只要这两个版本没问题，其它都好解决。但是对于 Android 和 iOS 上的，历史发布版本显然就重要的多，比如想在 iPad 3 上复现一个老版本的问题，发现居然连老版本的包都没了，这还谈啥复现。

作者：laofo

链接：https://www.jianshu.com/p/275ac8937a53

来源：简书

简书著作权归作者所有，任何形式的转载都请联系作者获得授权并注明出处。