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

Question

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

5

我们的构建/部署过程非常繁琐，需要足够的手动操作并容易出错。您能提出改进方案吗？

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

因此，我们有两种类型的补丁：Web 应用程序补丁（针对不同的环境）和配置补丁（针对每个实例的配置）。

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

我们构建这些补丁的方式是：

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

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

- Rorick

1个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- O. Jones · Accepted Answer

我所在的工作地方也遇到过类似的问题，但可能不太复杂。

我们的解决方案是完全取消补丁的概念。即使只是做了一点小改变，我们也停止打补丁，开始简单地安装整个应用程序。

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

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

取消打补丁让一些人感到困惑，他们质疑：“如果你只是改了几个东西，这样做岂不是浪费？”，“为什么要覆盖所有软件来修补某些东西？”

但事实上，良好的源代码控制、自动化的安装包构建和一步完成的安装过程节省了我们大量的时间。虽然安装需要多花几秒钟，但我们可以更频繁地进行安装，而且开发人员的工作量更少。