我们的构建/部署过程非常繁琐，需要大量手动操作且容易出错。您能提出改进建议吗？
那么让我描述一下我们的部署策略和构建过程。
我们正在开发名为Application Server(简称AS)的系统。它本质上是托管在 JBoss Web 服务器上的基于 servlet 的 Web 应用程序。 AS可以安装在两个“环境”中。每个环境都是一个包含 webapp 代码的目录。这个目录放在网络存储上。存储安装到安装了 JBoss 实例的多个生产服务器上。目录链接到 JBoss 的 webapps 目录。因此，所有 JBoss 实例都使用相同的环境代码。 JBoss 的配置独立于环境，并在每个实例的基础上进行更新。
所以我们有两种类型的补丁:webapp 补丁(针对不同的环境)和配置补丁(针对每个实例的配置)
补丁是一个可执行文件。实际上它是带有嵌入式二进制 rpm 包的 bash 脚本。安装非常简单:您只需执行文件并选择回答一些问题。重要的一点是补丁不是整个系统——它只包含一些带有修改配置文件的修复和/或脚本的类。将类复制到 WEB-INF/classes(AS 部署为展开目录)。
我们构建这些路径的方式是:
- 我们获取一些以前的补丁文件并复制它们。
- 我们修改补丁的内容。其中最重要的部分是 RPM 规范。在那里，我们更改了补丁的名称，更改了其必备的 rpm 包，并记下了用于备份、复制和修改文件的实际 bash 命令。这是最烦人的部分之一，因为我们并不总能获得实际的变更集。对于跨越多个变更请求和提交的新的复杂特性尤其如此。此外，为变更集编写这些命令既乏味又容易出错。
- 对于 webapp 补丁，我们还修改了其他环境的规范。通常它们是相同的，除了 rpm 包名称。
- 我们将所有 rpm 相关文件放到 VCS
- 我们通过添加几个用于构建新补丁的目标来修改 build.xml。修改是通过复制粘贴和编辑完成的。
- 我们通过复制粘贴项目并更改其中的 ant 目标来修改 CruiseControl 的配置
- 最后，我们建立了一个系统
此外，我对有关补丁准备和部署实践的任何引用资料感兴趣，最好是针对 Java 应用程序。我用谷歌搜索没有成功。
最佳答案
我工作的地方也有类似的问题，但可能没那么复杂。
我们的回应是完全消除补丁的概念。我们停止打补丁，并开始简单地安装整个应用程序(即使我们只做了一个小改动)。
我们现在有 Cruise Control 构建完整的安装套件，这些安装套件恰好在安装套件名称中包含构建时间戳。这是 Cruise Control 构建工件。
Cruise Control 将它们自动安装在测试服务器上，并运行一些自动冒烟测试。然后我们在测试服务器上运行手动测试。然后我们将工件安装在临时服务器上，然后是生产服务器。
取消打补丁让一些人气急败坏，“如果你只是改变一些东西，那不是很浪费吗？”以及“为什么要覆盖所有软件只是为了修补某些东西？”
但事实是，良好的源代码控制、自动安装工具包构建和一步安装为我们节省了大量时间。安装确实需要多花几秒钟的时间，但我们可以重复安装更多次，而且开发人员的工作量更少。
关于java - 如何改进我们的构建和部署过程？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/3265299/