正如我被评论过的，Shabunk继承了多年开发人员的经验，Maven正在驱动您以最佳方式完成您想要的事情。

我会解释我会做的事情（以及我本人真正要做的事情）。

因此，您正确使用Maven Release Plugin，再加上一个（例如，货运），您正在尝试做两种不同的事情：

• 识别唯一的版本，这意味着对其进行标记，并为新版本更新pom
• 部署您的应用程序（无论是哪个环境）

Maven发布插件

考虑到您自己的流程可能比其他开发团队所习惯的更加清晰。我的意思是，在较大的团队中，单元测试和生产部署之间需要采取更多步骤（Q＆A，用户接受度，非回归标准）。看来您做了链接标签和生产部署的快捷方式。如果要在不同的环境（集成，用户接受度，性能，预生产等）上部署Web应用程序，则必须标识您的版本并必须能够再次构建它（确定并“可重复”）。

那就是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>

部署

同样，您可能要在多个环境中测试您的应用程序。有许多插件可让您发送和部署战争：一般的货物插件，或更具体的tomcat插件，glassfish插件，…插件使您能够做自己想做的事情。然后，可以以多种方式执行配置。

完整的Maven方式：
与Maven的完整集成方式是使用Profile或Filters。如您所知，配置文件可以描述特性和行为。过滤器是.properties的一种，它对一组变量进行分组，这些变量将用于将xml配置文件中的模式替换为war（例如db连接）。它不是我使用的那个，因为我发现它不如外部化文件灵活。但是不要紧

Maven及其生态系统： 我更喜欢用Maven和Jenkins（或Continuous
Integration工具）构建应用程序。这就是为什么我同意亚伦说您必须了解您的工具的局限性的原因。使用Jenkins，我每天/每个小时都要针对单元测试，生成的问答报告，文档等等运行我的应用程序……我有一个发行版，可以帮助我制作出想要交付给我的所有内容（交付给我的测试团队或客户），我为工作提供了一些信息，以将其部署到不同的环境中（使用maven配置文件或jenkins内置配置）。

它对我来说真的很好，我很确定这是正确的方法。

[编辑]

部署方式

再次，部署意味着生命周期的不同阶段。

本地/开发环境

到目前为止，我永远不会使用tomcat：deploy，只是因为我更喜欢将码头用作轻型Web容器（并与maven很好地集成在一起）。但是我很确定每种配置都可以满足您的需求。

连续集成环境 在连续集成环境中，我通常直接与Jenkins复制战争（在所需的计算机上导出* .war）。我的工作方式取决于很多事情：

• 如果CI soft与您的应用程序服务器（Tomcat，Jboss，Weblogic，Glassfish等）位于同一台（物理）服务器上，或者远程服务器=>复制时间将浪费服务器刷新时间，并且会产生不安全的部署（通常是损坏的档案）
• 服务器是否支持热重载（对于Tomcat，Web应用程序中发生了爆炸式战争）或至少知道文件系统修改（对于JBoss，在/ deploy中进行了全面战争）
• 如果您需要先停止服务器，…

大多数时候，它是一个简单的副本。如果不能，我将使用一些集成的M​​aven插件（例如著名的CMS的jahia：deploy插件：www.jahia.com），或者仅使用cargo插件：http
://cargo.codehaus.org/Maven2+plugin
。我没有任何示例，但是在Internet上找到一些示例确实很容易，因为通常建议使用此配置。

问答/验收/生产环境

对于那些经常（据我在工作中所见）处理服务水平协议的环境，我们（我或管理团队）编写了一些特定的脚本。我敢肯定您会失望的，但是正如我提到的，我并不依赖Maven来完成所有事情，尤其是部署。恕我直言，这是此工具的一个限制。您也许可以依靠货运插件，也可以依靠特定的插件，但可以发布一个版本，或者构建一个与实际部署不匹配（按时间顺序）的版本。更重要的是，我找不到任何可以轻松在多个实例上进行部署的插件……甚至值得您以特定顺序关闭实例（SLA的需要）。就是说，我没有提到外部属性，SQL脚本或其他任何内容。它们是依赖专用工具的其他原因。

因此，通常，我们编写了自己的ant / sell脚本。如果其他人有更好的解决方案，那么我显然很困惑！

我希望我足够清楚。

问候。