处理多平台(dev/integ/valid/prod ...)开发的最佳解决方案是什么？交货过程

Question

我不是那么有经验,但我在一些大型Java EE项目(使用maven2)上工作,使用非常独特的方式来处理不同平台上的安装/交付.

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

• 战争/耳朵文件
• 项目清单
• 属性文件
• sgdb文件
• 其他一些人

团队将使用该文件将新的应用程序版本放在不同的平台上.我认为这个过程是严格的,并且允许你总是容易地保持生产中传递的不同配置,但它不是很灵活,过程有点沉重,它让我们有时做一些肮脏的事情,比如重写一类战争补丁回归......这是一个电子商务网站,每月有1000万独立访客,可用率为99.89%.

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

我想根据网站,公众展示和所需的可用性,我们必须根据需要调整交付策略.

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

Answer 1

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

• 在“PC”上进行开发，在我们的例子中是指 Windows——遗憾的是目前仍然是 Windows Xp——（以及单元测试）
• Linux 上的持续集成和系统测试（因为它们的安装成本更低）
• Solaris 上的预制作和制作（例如 Sun Fire）

我看到的常见方法是：

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

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

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

（这不是详尽的列表。
根据应用程序发布的性质，还必须解决其他问题）