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

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. 我们通过复制粘贴项目并更改其中的 ant 目标来修改 CruiseControl 的配置
7. 最后，我们构建了一个系统

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

Answer 1

我工作的地方也有类似的问题，但可能没有那么复杂。

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

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

Cruise Control 会在测试服务器上自动安装它们，并运行一些自动冒烟测试。然后我们在测试服务器上运行手动测试。然后我们将工件安装在暂存服务器上，然后是生产服务器。

去掉补丁让一些人怒不可遏，“如果你只是改变一些东西，那不是很浪费吗？”和“你为什么要覆盖所有的软件只是为了打补丁？”

但事实是，良好的源代码控制、自动安装套件构建和一步安装为我们节省了大量时间。安装确实需要几秒钟的时间，但我们可以更重复地完成安装，并且开发人员的劳动力更少。