我必须承认，我经过多年生活在可怕的debuild/ANT/Makefile的嵌合体结构的世界是新的Maven的世界。我只是没有那种能帮助经验丰富的开发人员选择正确决策的感觉，而且看起来在maven中有很多不同的方法。部署到生产用最简单的方法是建立一个
所以，我有一个简单的项目包含Web应用程序。我想基本如下：
为区分开发和生产我已创建配置文件，dev和prod。 dev配置文件默认处于激活状态。当我要部署的东西到生产，我只需键入mvn -P prod tomcat:deploy
我读过关于发布插件，以及有关buildnumber插件。 但我只是不确定我是否正确。
所以，问题是 - 什么是最succint，自足和“mavenish”的方式来解决，我问的任务。
Shabunk，正如我所评论的那样，Maven正在推动你以最佳方式做你想做的事，从多年的开发经验中继承下来。
我会解释我会做什么（以及我自己真的）。
所以你有权使用Maven插件版，再加上另外一个（货物为例） 你试图做两型动物的事情：
Maven发布插件
考虑一下，你自己的过程也许比其他开发团队习惯的更为严格。我的意思是在大型团队中单元测试和生产部署之间有更多步骤（Q & A，用户接受度，非回归活动）。看起来你制作了一个链接标签和生产部署的快捷方式。 如果你想在不同的环境中部署你的web应用（集成，用户接受，性能，preprod等），你必须确定你的版本，并且必须能够重新构建它（当然和“可重复”）。
这是maven-release-plugin的意图。它可以帮助您验证源代码是否干净（所有源代码管理下的文件，无需修改），可以编译并通过所有测试阶段。然后，它会处理pom版本和标记，并将其存储起来，以便稍后在您的Maven企业存储库中使用。
你有很多配置可以设置（ditributionManagement，SCM，maven插件发布配置）。但是，一旦它在的地方，释放版本站在一个简单的命令行：
mvn release:prepare release:perform
如果你想要一些例子，我可以给你一些。
<scm>
<!-- Base URL repository -->
<url>scm:svn:http://svn.myorg.corp/svn/repository/</url>
<!-- Developper URL (from trunk or branche) -->
<developerConnection>scm:svn:http://svn.myorg.corp/svn/repository/trunk/project1</developerConnection>
<connection>scm:svn:http://svn.myorg.corp/svn/repository/trunk/project1</connection>
</scm>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-scm-plugin</artifactId>
<version>1.6</version>
<configuration>
<username>${from.settings.xml.user}</username>
<password>${from.settings.xml.password}</password>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-release-plugin</artifactId>
<version>2.2.2</version>
<configuration>
<tagBase>http://svn.myorg.corp/svn/repository/tags/</tagBase>
<scmCommentPrefix>[DEV#SCM]</scmCommentPrefix>
</configuration>
</plugin>
</plugins>
[...]
</build>
<distributionManagement>
<repository>
<id>enterprise_repo</id>
<name>Enteprise Repository on Artifactory - Stable versions</name> <url>http://repo.corp:8080/artifactory/prj-xxx-releases</url>
</repository>
<snapshotRepository>
<id>enterprise_repo</id>
<name>Enteprise Repository on Artifactory - DEV versions</name>
<url>http://repo.corp:8080/artifactory/prj-xxx-snapshots</url>
</snapshotRepository>
<site>
<id>corporate_site</id>
<name>Corporate public site</name>
<!-- must add wagon plugin that support this protocol -->
<url>ftp://...</url>
</site>
</distributionManagement>
Deployement
再次，你可能对你想测试你对应用程序的多个environnements。 有很多插件可以让你发送和部署你的战争：一般的货物插件，或更具体的tomcat插件，glassfish插件，...插件让你做你想做的事。然后，可以以多种方式执行配置。
完整的Maven方式： 与Maven的完整集成方式是使用Profile和可能的过滤器。如你所知，档案让你描述合适的人和行为。过滤器是一种.properties，它将一组变量分组，用于将xml配置文件中的模式替换为war（例如db连接）。这不是我使用的，因为我觉得它比文件外化更不灵活。但无论如何，我更喜欢使用Maven和Jenkins（或连续集成工具）构建我的应用程序。这就是为什么我同意亚伦时他说你必须知道你的工具的局限性。使用Jenkins，我每天/每天运行我的应用程序，以应对单元测试，生成Q &报告，文档...我有一个发布版本，可以帮助我生成我想要交付的所有内容（给我的测试团队或我的客户），并提供一些信息给我的工作部署到不同的环境（使用maven配置文件或jenkins内置配置）。
它对我来说真的很好，我很确定这是正确的做法。
[编辑]
部署
再次，部署意味着生命周期的不同阶段。
本地/开发环境在
我从来没有使用Tomcat：部署到现在为止，但仅仅是因为我更喜欢使用码头轻Web容器（和良好使用Maven集成）。但是我很确定，每一个配置都会适合你的需求。
持续集成环境公司 在持续集成环境在，我通常是战争直接与詹金斯（出口*所需的机器上的.war）复制。我这样做的方式取决于许多因素：
大多数的时间，这是一个简单的复制。如果我不能，我使用一些集成的Maven插件（如jahia：部署插件用于着名的CMS：www.jahia.com），或者仅使用货物插件：http://cargo.codehaus.org/Maven2+plugin。我没有任何例子，但在互联网上很容易找到一些例子，因为这种配置通常会被推荐。
Q & A /承兑/生产环境在
对于那种environnements，往往（据我，因为我在我的工作所看到的）与服务级别协议的交易，我们（我和管理团队）写了一些特定的脚本。我相信你会失望，但正如我所说的，我不依赖于Maven的一切，特别是部署。恕我直言，这是这个工具的一个限制。你可以依靠货物插件或者特定的插件，但是发布一个版本，或者建立一个版本不符合（按时间顺序）真正的部署。更重要的是，我没有发现任何让我轻松部署多个实例的插件......甚至值得您必须以特定顺序关闭实例（SLA的需求）。这就是说，我没有提到外部属性或SQL脚本或其他任何东西。他们是依赖专用工具的其他理由。
所以，通常，我们编写了自己的蚂蚁/卖出脚本。如果其他人有更好的解决方案，我显然是有兴趣的！
我希望我已经够清楚了。
问候。
Mavenized解决方案不是在常见情况下出现异常时使用Maven。 Maven都是关于常见的情况。异常在其他地方处理，这意味着POM（应该）永远不会包含任何意外。
由于您需要自定义部署过程，因此您需要编写一个shell脚本或Ant build.xml，它执行必要的步骤，并在此过程中使用Maven进行部署。
这样，每个工具都能做到最好。
[编辑]注意所有downvoters在那里：除非你有一个参数，你的投票表决意味着什么。 Maven是一个工具。像所有工具一样，它有限制。 Maven的核心理念是避免例外。蚂蚁是关于角落案件的，Maven是关于主流的。从 “What is Maven?” 页：
- 使构建过程中容易
- 提供统一构建系统
（我的重点）所以，是的，有些事情对于这Maven并不是最好的解决方案。如果标准版本过程适用于您，请使用release plugin。
但是，如果没有，那么看看其他地方，而不是下降的“everything looks like a nail”心灵陷阱。
一个主要的个人发展步骤是要了解你自己的极限和你一起工作的工具的限制。当一个工具不适合工作时，尝试一种不同的工具，而不是试图扭曲现实。你的生活会更开心。
原始问题要求使用Maven进行生产部署的“最佳实践”。我希望获得不止一个“最佳实践”，并提供赏金以查看不同的解决方案并向他们学习。我不在乎他们是纯粹的Maven解决方案还是他们使用不同的工具。
与此线程并行我也做了一些研究，并希望在这里发布我看到的不同方法。我试过1）和3），他们是纯粹的maven，不管Aaron在说什么，他们也在工作。
在我目前的项目中，我有一个开发环境，一个测试环境，一个临时环境和一个生产环境。从我的maven pom中，我想与开发环境一起工作，并仅部署到测试环境。我看到与Maven POM以下方法：
在所有解决方案中，我正在使用集成测试（surefire插件），版本插件和发布插件来构建战争。对于部署，我正在按照https://stackoverflow.com/a/1151870/734687（一个表达我非常喜欢的帖子）的参数实现方法3。
由于应用程序必须在所有环境中保持不变，因此必须区分运行时的不同设置，这可能非常复杂。我们的操作团队希望为容器外的每个应用程序设置设置，所以我支持一个环境变量，它指向我的正确目录，但是是可选的。如果没有设置，那么我使用战争中的开发设置。在这里看到一个春天样本：
<bean class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
<property name="ignoreResourceNotFound" value="true"/>
<property name="locations">
<list>
<value>classpath:META-INF/spring/*.properties</value>
<value>file:///${picservice.configdir:-}/*.properties</value>
</list>
</property>
</bean>
在META-INF /弹簧DIR总是加载的特性。另外我从文件系统集成了可以覆盖上述属性的属性。如果没有发现任何属性，这将不会触发怀疑，因为我设置了ignoreResourceNotFound。如果设置了属性picservice.configdir，它会将我引导到一个目录，如果不是，我提供了默认值:。 -表示我不想要当前目录的值。
对于日志我有类似的解决方案。你可以找到有关属性很有趣的文章，文件和Spring处理在下面的链接：
我发现一个有趣的演示这个主题，请参阅Automated Deployment with Maven and friends。
-1如何使用配置文件更新git repo？配置文件如何增加内部版本号？当标准的Maven插件不能像你那样工作时，你如何做到这些？ – 2012-06-08 19:14:15
1）你的答案仍然没有说明Maven如何做到这一点。我的构建和标准插件都有同样的问题，因此我不需要做任何事情。 2）我用我的所有版本Maven。这是我的标准工具。我为它编写了插件并修补了现有的插件。最重要的是，我知道限制是什么。 – 2012-06-09 12:07:20
好主意你的赏金！ – 2012-06-09 21:28:16
更新git回购，添加标签提交和升级构建版本。
-
我读过关于发布插件，以及有关buildnumber插件。 但我只是不确定我是否正确。
是的，使用release插件是推荐的方法。如果你想在一些文档中使用buildnumber，你可以使用buildnumber插件。 CHANGES.txt
我认为最简单的方式来完成您指定什么（如果我深知）是配置Maven Release Plugin如下：
<!-- path: project/build/pluginManagement/plugins -->
<plugin>
<artifactId>maven-release-plugin</artifactId>
<configuration>
<releaseProfiles>prod</releaseProfiles>
<goals>tomcat:deploy</goals>
</configuration>
</plugin>
用于开发部署，继续为你做的：（如果dev是活跃在默认情况下删除该-P dev论证）。
释放时分两步进行如下Maven Release Plugin预计：
mvn release:prepare
这一目标将增加版本和标签，只要你想（and more）。请注意，您还需要指定什么SCM的Maven应在POM配置这个标签使用：
<!-- path: project -->
<scm>
<connection>scm:git:ssh://yourrepo.url</connection>
</scm>
SCM plugin支持wide variety of SCM managers and protocols（你可能会感兴趣的git:http或git:https）。
然后
mvn release:perform
这将使用的配置文件prod和简单的运行目标tomcat:deploy，你配置了什么。
我希望这是你所需要的。问候。
配置文件以哪种方式支持您在git仓库中添加标签并递增构建版本？ Maven就像一把锤子一样的工具 - 它不适合每一项任务。 – 2012-06-08 19:10:43
你的基本前提错了。 – 2012-06-09 13:36:33
我完全同意你的看法。 Maven是我认识的推动开发生命周期的最佳实践的更好工具之一。如果你没有使用它，那很可能是因为你不正确（关于最佳实践）。所以你必须委托给其他工具，通常是Ant，Jenkis或其他工具。对于传统项目来说这很困难，通常是不可能的，但它代表正确的方式来做到这一点...... +1！ – 2012-06-09 20:15:32