我们正在调整我们的构建和安装;发布我们的一个基于Java的产品的程序，以支持补丁/修补程序版本。
今天，我们从构建管道中提供完整的安装包（这是一组包装在ISO中的RPM包）。但是，我们的目标也是支持增量/更细粒度的升级/补丁发货。
为了简单起见，我们计划使用更精细的RPM包并在专用的修补程序ISO中打包这些RPM的子集（仅在发行版的范围内更改）以及完整的安装ISO。 （我们还考虑了其他选项，如二进制差异 - 增量RPM - 创建单独的修补程序RPM等。）
我想了解一下如何管理构建管道 - 打包和版本控制（因为这也是核心版本管理问题），以支持这种修补程序部署？
答案 0 :(得分：1)
我想知道你是怎么回事 管理您的构建管道 - 包装 和版本控制
我介绍了一个（工作）概念：
Bugreport作为bug711之类的标识所有触及修复此错误的来源都将被标记（版本控制），错误报告号为。
此标记可用于签出创建补丁所需的所有源（如果涉及静态文件，如html，js，css等），并从分支合并到头版本。
在java代码的情况下，部署的最小值是工件（jar，ear，war-file）。 这需要重新启动应用程序。对于JBoss Application Server，我们发现“爆炸式”部署允许我们在没有停机的情况下进行修补。
这实际上取决于服务器环境以及哪种方法最适合您的应用程序。我担心没有单一的最佳实践。