修补程序/修补程序构建和交付方法

我们正在调整我们的一个基于Java的产品的构建和发布过程，以支持补丁/修补程序版本。

今天，我们从构建管道中提供完整的安装包（这是一组包装在ISO中的RPM包）。但是，我们的目标也是支持增量/更细粒度的升级/补丁发货。

为了简单起见，我们计划使用更精细的RPM包，并在专用的修补程序ISO和完整的安装ISO中打包这些RPM的子集（仅在发行版的范围内更改）。（我们还考虑了其他选项，如二进制差异 – delta RPMs – 创建单独的修补程序RPM等）

我想了解一下如何管理构建管道 – 打包和版本控制（因为这也是核心版本管理问题），以支持这种修补程序部署？

我想了解您如何管理构建管道 – 打包和版本控制

我介绍了一个（工作）概念：

Bugreport作为bug711之类的标识所有触及修复此bug的来源都将被标记（版本控制），错误报告号为。

此标记可用于检出创建补丁所需的所有源（如果涉及静态文件，如html，js，css等），并从分支合并到头修订。

在java代码的情况下，部署的最小值将是工件（jar，ear，war-file）。这需要重新启动应用程序。在JBoss Application Server的情况下，我们发现“爆炸式”部署允许我们在没有停机的情况下进行修补。

这实际上取决于服务器环境以及哪种方法最适合您的应用程序。我担心没有单一的最佳实践。