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

时间:2010-12-29 12:48:30

标签: java svn git maven-2 java-ee

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

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

  • war / ear files
  • 列表项
  • 属性文件
  • sgdb文件
  • 其他人

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

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

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

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

5 个答案:

答案 0 :(得分:3)

在不处理网站交易的情况下,我不得不参与异构环境中各种大型(Java)项目的发布管理流程:

  • 在“PC”上的开发,在我们的案例中意味着Windows - 现在可悲的是Windows Xp - (和单元测试)
  • 在linux上进行持续集成和系统测试(因为它们设置起来更便宜)
  • 在Solaris上进行预生产和生产(例如Sun Fire)

我看到的常用方法是:

  • 二进制依赖项(每个项目使用其他项目生成的二进制文件,而不是其源代码)
  • 没有针对集成测试的重新编译(在PC上生成的jar直接在linux场上使用)
  • 完全重新编译预生产(意味着存储在Maven仓库中的二进制文件),至少是为了确保使用相同的JDK和销售选项重新编译所有
  • 生产系统上没有VCS(版本控制系统,如SVN,Perforce,Git,Mercurial等):所有内容都是从pre-prod到rsynch部署的。

因此,发布管理过程需要考虑的各种参数是:

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

(这不是一个详尽的清单 根据应用程序版本的性质,必须解决其他问题)

答案 1 :(得分:3)

对此的答案根据具体要求和团队结构而有很大差异。

我已经为一些具有类似可用性要求的非常大的网站实施了流程,并且我发现有一些一般原则可用:

  • 外部化任何配置,以便可以在所有环境中运行相同的构建工件。然后只为每个版本构建一次工件 - 为不同的环境重建是耗时且有风险的,例如它与您测试的应用程序不同
  • 集中构建工件的位置。 - 例如所有用于生产的战争都必须打包在CI服务器上(使用hudson上的maven发布插件对我们来说很有效)。
  • 发布的所有更改必须是可追踪的(版本控制,审核表等),以确保稳定性并允许快速回滚和&诊断。这并不意味着重量级的过程 - 请参阅下一点
  • 自动化所有内容,构建,测试,发布和回滚。如果该过程可靠,可自动化且快速,则可以将相同的过程用于从快速修复到紧急更改的所有事项。我们使用相同的流程进行快速5分钟紧急修复和主要版本,因为它是自动化且快速的。

一些额外的指示:

请参阅我的回答property-placeholder location from another property,了解使用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

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

希望这会有所帮助 - 祝你好运。

答案 2 :(得分:1)

要添加到我之前的答案中,您所处理的内容基本上是CM-RM问题:

  • CM(变更管理)
  • RM(发布管理)

换句话说,在第一次发布之后(即主要的初始开发结束),你必须继续发布,这就是CM-RM应该管理的内容。

在您的问题中,RM的实现可以是1)或2),但我的观点是添加到该机制:

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

答案 3 :(得分:1)

在不声明它是最佳解决方案的情况下,这就是我的团队目前进行分段和部署的方式。

  • 开发人员最初在本地机器上开发,可以自由选择操作系统,但我们强烈建议使用与生产中使用的相同的JVM。
  • 我们有一个 DEV 服务器,其中经常推送代码的快照。这只是来自IDE生成的二进制构建的scp。我们计划直接在服务器上构建。
  • DEV 服务器用于利益相关者不断窥视开发。就其本质而言,它是不稳定的。这对于此服务器的所有用户来说都是众所周知的。
  • 如果代码足够好,它会分支并推送到 BETA 服务器。同样,这是来自IDE的二进制构建的scp
  • 测试和一般质量检查在此 BETA 服务器上进行。
  • 同时,如果当前正在生产的软件需要进行任何紧急更改,我们会有一个名为 UPDATE 服务器的第三台临时服务器。
  • UPDATE 服务器最初仅用于暂存非常小的修复程序。我们也使用scp复制二进制文件。
  • 更新上进行所有测试后,我们会将构建从 UPDATE 复制到 LIVE 。什么都没有直接进入实时服务器,它总是通过更新服务器。
  • 当所有测试在 BETA 上完成后,测试版本将从测试版服务器复制到 UPDATE 服务器,并执行最后一轮完整性测试。由于这是在测试版服务器上测试的确切版本,因此在此阶段发现问题的可能性非常小,但我们坚持规则,即部署到实时服务器的所有内容都应该通过更新服务器以及更新中的所有内容服务器应该在移动之前进行测试。

这种滑动策略允许我们并行开发3个版本。版本N目前正在制作并通过更新服务器上演,版本N + 1将是即将发布并将在测试版服务器上发布的下一个主要版本,而版本N + 2将是下一个主要版本目前正在进行开发并在开发服务器上进行。

我们做出的一些选择:

  • 完整应用程序(EAR)通常依赖于其他项目的工件。我们选择包含其他项目的二进制文件,而不是从源代码构建整个项目。这简化了构建,并更好地保证了经过测试的应用程序与所有依赖项的正确版本捆绑在一起。成本是必须手动将这种依赖项中的修复程序分发给依赖它的所有应用程序。
  • 每个分段的配置都嵌入在EAR中。我们目前使用命名约定,脚本将每个配置文件的正确版本复制到正确的位置。参数化每个配置文件的路径,例如目前正在考虑在根配置文件中使用单个{stage}占位符。我们将配置存储在EAR中的原因是因为开发人员是引入和依赖配置的人,所以他们应该负责维护它(添加新条目,删除未使用的条目,调整现有条目等)。
  • 我们对部署团队使用DevOps策略。它由一个纯粹是开发人员,两个既是开发人员又是操作人员以及两个纯粹操作人员组成。

将配置嵌入EAR可能会引起争议,因为传统上操作需要控制例如生产中使用的数据库数据源(它指向的服务器,允许连接池的连接数等)。但是,由于开发团队中的人员也在运营,因此他们可以在代码仍在开发过程中轻松地检查配置中其他开发人员所做的更改。

与分段并行,我们让连续构建服务器服务器在每次签入后执行脚本(ANT)构建(每5分钟最多一次),并运行单元测试和其他一些完整性测试。

仍然很难说这是否是最佳方法,我们一直在努力改进我们的流程。

答案 4 :(得分:1)

我是一个单一部署,包含所有(代码,配置,数据库Delta,...)适用于所有环境的大力倡导者,集中构建和发布CI服务器。

这背后的主要思想是 Code,Config&无论如何,DB Delta紧密耦合。代码依赖于在配置中设置的某些属性以及DB中存在的一些对象(表,视图等)。那么为什么要分开这个并花时间跟踪所有内容以确保它们在一起,当你可以将它们放在一起时。

另一个重要方面是最大限度地减少环境之间的差异,将失败原因降至最低。

持续投放关于Parleys的更多详细信息:http://parleys.com/#id=2443&st=5