处理多平台的最佳解决方案是什么(dev/integ/有效值/prod.)发展？交付过程

Question

我不是很有经验，但我在一些大型Java项目(使用maven2)上使用了非常不同的方法来处理不同平台上的安装/交付。

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

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

团队将使用这些文件将新的应用程序版本放到不同的平台上。我认为这个过程是严格的，允许你总是很容易地保持不同的配置在生产中通过，但它不是真正的灵活，这个过程有点重，它引导我们有时做一些肮脏的事情，如推翻一个类别的战争，以修补一个回归……这是一个电子商务网站，每月有1000万独特的访问者和99.89%的可用性。

2)我看到的另一个方法是签出每个平台上的源，然后在本地存储库中安装快照工件。然后，应用服务器将使用.m2文件夹的这些快照。没有一个真正的交付过程，因为要在生产中添加一个新版本，我们只需更新组件/webapp的来源，完成一些maven干净的安装并重新启动应用服务器。我认为它更灵活，但我看到了一些缺点，这种方法对我来说似乎很危险。这个网站有一个前端，我不知道数字，但它远远低于第一个。该公司还为13万人的公司的大多数员工提供了一个大型后台办公室。

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

我不是来问哪种解决方案是最好的，而是想知道你是否见过不同的东西，在这种情况下你会采用什么策略？

Answer 1

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

• 对"PC“的开发，在我们的例子中，意思是Windows --可悲的是，目前仍然是Windows -(以及单元测试)
• linux上的持续集成和系统测试(因为安装起来更便宜)
• Solaris的前期生产和生产(例如太阳烈火)

我看到的常见方法是：

• 二进制依赖关系(每个项目使用由另一个项目生成的二进制文件，而不是它们的源)
• 不为集成测试重新编译( PC上产生的jars直接用于linux农场)
• 对预生产(即存储在Maven回购上的二进制文件)进行完全重新编译，至少是为了确保使用相同的JDK和sale选项重新编译所有内容。
• 没有VCS (版本控制系统，如SVN，Perforce，Git，Mercurial，.)在生产系统上:所有的东西都是从预驱动到同步部署的。

因此，在发布管理过程中要考虑的各种参数是：

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

(这并不是一个详尽的清单。

取决于应用程序发布的性质，还必须解决其他问题)

Answer 2

这个问题的答案因确切的需求和团队结构的不同而有很大差异。

我为几个具有类似可用性要求的大型网站实现了流程，并且我发现有一些通用的原则奏效了：

• 将任何配置外部化，这样就可以在所有环境中运行相同的构建工件。然后，只为每个版本构建一次工件--为不同的环境重新构建一次是耗时和冒险的，例如，它与您测试的应用程序不同。
• 集中建造文物的地方。-例如，所有用于生产的wars必须打包在CI服务器上(在hudson上使用maven发布插件对我们很好)。
• 发布的所有更改必须是可跟踪的(版本控制、审核表等)，以确保稳定性并允许快速回滚和诊断。这并不意味着一个重量级的过程--参见下一点
• 自动化一切，构建、测试、发布和回滚。如果流程是可靠的、自动化的和快速的，那么相同的流程可以用于从快速修复到紧急更改的所有东西。我们使用相同的过程快速5分钟的紧急修复和一个主要的发布，因为它是自动化和快速的。

一些额外的指示：

有关使用spring加载每个环境的不同属性的简单方法，请参见我的答案属性-来自另一个属性的占位符位置。

http://wiki.hudson-ci.org/display/HUDSON/M2+Release+Plugin如果使用此插件并确保只有CI服务器才有正确的凭据来执行maven版本，则可以确保所有版本的执行都是一致的。

http://decodify.blogspot.com/2010/10/how-to-build-one-click-deployment-job.html --部署发行版的简单方法。虽然对于大型站点，您可能需要一些更复杂的东西来确保不停机--例如，一次部署到一半的集群，并在两个部分- http://martinfowler.com/bliki/BlueGreenDeployment.html之间切换web流量。

http://continuousdelivery.com/是一个很好的网站和书籍，有一些很好的发布模式。

希望这能帮上忙-祝你好运。

Answer 3

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

• CM (变革管理)
• RM (发行管理)

换句话说，在第一个版本之后(即主要的初始开发已经结束)，您必须继续发布，这就是CM应该管理的内容。

在您的问题中，RM的实现可以是( 1)或( 2)，但我的要点是在该机制中添加以下内容：

• 适当的CM，以便跟踪任何更改请求，并在承诺进行任何开发之前评估其影响。
• 适当的RM，以便能够实现“发布”测试(系统、性能、回归、部署测试)，然后规划、调度、执行并监视发布本身。