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

Question

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

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

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

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

我们建立这些pathes的方法是：

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

另外，我感兴趣的是在贴剂和部署实践的任何引用，最好是Java应用程序。我没有成功使用Google搜索。

Answer 1

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

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

我们现在有巡航控制构建完成安装工具包，恰好包含安装套件名称中的构建时间戳。这是巡航控制构建神器。

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

摆脱打补丁导致一些人慌张，“如果你只是在改变一些事情，这不是浪费吗？”和“为什么你会覆盖所有的软件来修补某些东西？”

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

Answer 2

我们也在尝试转向修补程序/修补程序版本以及发布基于RPM的完整安装软件包。

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

在我们的案例中，我们有一个多模块交付，每个包装为一个RPM并包装在ISO中进行交付。我们的目标是保持我们的构建管线大部分不变，以便发布修补程序。因此，我们将重点放在使我们的RPM更加细化（更小更有针对性的RPM），以便我们只能发布包含某个修补程序/修补程序的已更改工件的RPM。

通过这种方式，完整版本的RPM和补丁RPM是相同的，唯一的区别是您在传送ISO中打包的RPM数量。

我还有一个问题解决这个问题，你可以看看有：

hotfix-patch-build-delivery-approach