如何改进构建和部署过程？

Question

我们的构建/部署过程非常繁琐，手动充足，容易出错。你能提出改进建议吗？

让我来描述一下我们的部署策略和构建过程。 我们正在开发名为Application Server（简称AS）的系统。它本质上是托管在JBoss Web服务器上的基于servlet的Web应用程序。 AS可以安装在两个“环境”中。每个环境都是一个包含webapp代码的目录。此目录位于网络存储上。存储安装到安装了JBoss实例的多个生产服务器。目录链接到JBoss'webapps目录。因此，所有JBoss实例都使用相同的环境代码。 JBoss的配置与环境分开，并且基于每个实例进行更新。

所以我们有两种类型的补丁：webapp补丁（针对不同的环境）和配置补丁（针对每个实例配置）

补丁是一个可执行文件。实际上它是带有嵌入式二进制rpm包的bash脚本。安装非常简单：您只需执行文件并可选择回答一些问题。重要的一点是补丁不是一个整体系统 - 它只包含一些带有修改和/或修改配置文件的脚本的类。将类复制到WEB-INF / classes中（AS部署为展开目录）。

我们构建这些方案的方式是：

1. 我们采用一些以前的补丁文件并复制它们。
2. 我们修改补丁的内容。其中最重要的部分是RPM规范。我们更改补丁名称，更改其先决条件rpm包并记下用于备份，复制和修改文件的实际bash命令。这是最讨厌的部分之一，因为我们并不总能获得实际的变更集。对于跨多个变更请求和提交的新复杂功能尤其如此。此外，为变更集编写这些命令很繁琐且容易出错。
3. 对于webapp补丁，我们还修改其他环境的规范。除了rpm包名之外，它们通常是相同的。
4. 我们将所有与rpm相关的文件放入VCS
5. 我们通过添加几个用于构建新补丁的目标来修改build.xml。修改是通过复制和编辑完成的。
6. 我们通过复制项目和更改其中的蚂蚁目标来修改CruiseControl的配置
7. 最后，我们构建了一个系统

此外，我对有关补丁准备和部署实践的任何参考感兴趣，最好是对Java应用程序。我没有成功用Google搜索。

Answer 1

我工作的地方有类似的问题，但也许并不复杂。

我们完全取消了补丁的概念。我们停止了修补，开始简单地安装整个应用程序（即使我们做了一个小小的改动）。

我们现在拥有Cruise Control构建完整的安装工具包，恰好包含安装工具包名称中的构建时间戳。这是一个Cruise Control构建工件。

Cruise Control在测试服务器上自动安装它们，并运行一些自动化的烟雾测试。然后，我们在测试服务器上运行手动测试。然后我们在临时，然后生产服务器上安装工件。

摆脱修补导致一些人喋喋不休，“如果你只是改变一些事情，那不是很浪费吗？”并且“为什么要覆盖所有软件只是为了补丁？”

但事实是，良好的源代码控制，自动安装工具包构建和一步安装为我们节省了大量时间。安装需要几秒钟的时间，但我们可以更多地重复这一过程，并减少开发人员的工作量。

Answer 2

我们还试图转向修补程序/修补程序版本，并发布基于RPM的完整安装包。

我必须说我也同意在大多数情况下这种努力是浪费，我也会发布完整的安装包，假设你已经建立了一个构建管道。

在我们的案例中，我们有一个多模块交付，每个交付打包为一个RPM并包装在ISO中以便交付。我们的目标是保持我们的构建管道线基本不变，以释放修补程序。因此，我们专注于使我们的RPM更细粒度（更小 - 更有针对性的RPM），以便我们只能释放那些包含特定修补程序/补丁的更改工件的RPM。

这样，完整版本的RPM和补丁RPM是相同的，唯一的区别是您在交付ISO中打包的RPM数量。

我有另外一个问题来解决这个问题，你可以看看那里：

hotfix-patch-build-delivery-approach