Java 处理多平台（dev/integ/valid/prod…）开发的最佳解决方案是什么？交付过程

我没有那么丰富的经验，但我在一些大型JavaEE项目（使用maven2）上工作过，使用非常独特的方法来处理不同平台上的安装/交付

1） 其中之一是使用快照进行开发，然后发布组件和主要Web应用程序的maven版本。因此，交付是：

• war/ear文件
• 列表项
• 属性文件
• sgdb文件
• 其他一些

团队将使用这些文件将新的应用程序版本放在不同的平台上。 我认为这个过程是严格的，允许您始终轻松地保留生产中传递的不同配置，但它不是真正灵活的，这个过程有点重，它引导我们有时做一些肮脏的事情，例如覆盖一个类的战争来修补回归。。。 这是一个电子商务网站，每月有1000万独立访客，99.89%的可用性

2） 我看到的另一个方法是签出每个平台上的源代码，然后在本地存储库中安装快照工件。然后应用服务器将使用.m2文件夹的这些快照。 没有真正的交付过程，因为要将新版本投入生产，我们只需更新组件/webapps的源代码，执行一些maven clean安装并重新启动应用程序服务器。 我认为它更灵活，但我看到了一些缺点，这种方法对我来说似乎很危险。 这个网站有一个前台，我不知道数字，但比第一个少得多。它还有一个庞大的后台办公室，可供13万人公司的大多数员工使用

我想，根据网站、对公众的展示以及所需的可用性，我们必须根据需要调整交付策略

---

我来这里不是想问哪种解决方案是最好的，而是想知道您是否看到了不同的东西，以及在哪种情况下您会使用哪种策略？

在不涉及网站的情况下，我不得不参与异构环境中各种大型（Java）项目的发布管理过程：

• 在“PC”上开发，在我们的例子中是指Windows——不幸的是，现在仍然是Windows Xp——（和单元测试）
• linux上的持续集成和系统测试（因为它们的安装成本较低）
• Solaris上的预生产和生产（例如Sun Fire）

我看到的常用方法是：

• 二进制依赖关系（每个项目使用另一个项目生成的二进制文件，而不是它们的源文件）
• 集成测试无需重新编译（PC上生产的JAR直接用于linux服务器场）
• 预生产时完全重新编译（意味着存储在Maven repo上的二进制文件），至少确保所有内容都使用相同的JDK和销售选项重新编译
• 在生产系统上没有VCS（版本控制系统，如SVN、Perforce、Git、Mercurial等）：从预生产到rsynch，一切都是部署的

---

因此，发布管理流程需要考虑的各种参数是：

• 开发项目时，是否直接依赖其他项目的源代码或二进制文件
• 设置值存储在哪里？
  您是否对它们进行了参数化，如果是，什么时候用它们的最终值替换变量（仅在启动时，或者在运行时？）
• 您是否在最终（预生产）系统上重新编译所有内容
• 如何在生产系统上访问/复制/部署
• 如何停止/重新启动/修补应用程序

（这不是一个详尽的列表。

---

根据应用程序版本的性质，必须解决其他问题）

要补充我之前的回答，您所处理的基本上是CM-RM问题：

• CM（变革管理）
• RM（发布管理）

换句话说，在第一次发布之后（即主要的初始开发已经结束），您必须继续发布，而这正是CM-RM应该管理的

在您的问题中，RM的实施可以是1）或2），但我的观点是要添加到该机制中：

• 适当的构型管理，以便跟踪任何变更请求，并在提交任何开发之前评估其影响
• 适当的RM，以便能够实现“发布”测试（系统、性能、回归、部署测试），然后规划、安排、执行并监控发布本身

---

这一问题的答案因具体需求和团队结构而异

我已经为一些具有类似可用性要求的大型网站实施了流程，我发现有一些通用原则行之有效：

• 外部化任何配置，以便相同的构建工件可以在所有环境中运行。然后只为每个版本构建一次工件-为不同的环境重建工件既耗时又有风险，例如，它不是您测试的同一个应用程序
• 集中建造人工制品的地方e、 g.所有用于生产的WAR都必须打包在CI服务器上（使用hudson上的maven发布插件对我们来说效果很好）
• 发布的所有更改必须是可跟踪的（版本控制、审核表等），以确保稳定性并允许快速回滚和诊断。这并不一定意味着一个重量级的过程——请看下一点
• 自动化一切，构建、测试、发布和回滚。如果这个过程是可靠的、自动化的和快速的，那么同样的过程可以用于从快速修复到紧急更改的所有事情。我们使用相同的过程进行5分钟的快速紧急修复和主要发布，因为它是自动化和快速的

一些额外的提示：

查看我的答案，了解一种简单的方法