tomcat - 使用build部署到生产的最简单方法

Question

我必须承认在生活在巨大的debuild / ant / makefile嵌合结构世界中多年后，我才是Maven世界的新手。我只是还没有那种感觉，可以帮助经验丰富的开发人员选择正确的决策，而且看来Maven有很多不同的方法。

因此，我有一个包含web-app的简单项目。
我基本上想要以下内容:

部署到开发Tomcat(我正在使用tomcat:deploy)，然后什么也不做。

部署到生产Tomcat，但是部署之前更新git repo，添加标记的提交并升级构建版本。

为了区分开发和生产，我创建了个人文件 dev和 prod。默认情况下， dev配置文件是激活的。当我想将某些东西部署到生产环境时，只需键入 mvn -P prod tomcat:deploy
我已经阅读了有关发布插件以及buildnumber插件的信息。
但是我不确定我是否会走对路。

因此，问题是-解决我要问的任务的最简洁，自成体系和“保守”的方法是什么？

Answer 1

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

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

因此，您正确使用Maven Release Plugin，再加上一个(例如， cargo )
您正在尝试做两种不同的事情:

标识唯一版本，这意味着对其进行标记，并为新版本更新pom

部署您的应用程序(无论是哪种环境)

Maven发布插件

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

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

部署

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

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

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

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

[编辑]

部署

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

本地/开发环境

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

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

，如果CI soft与您的应用程序服务器(Tomcat，Jboss，Weblogic，Glassfish等)位于同一台(物理)服务器上，或者远程服务器=>复制时间将浪费服务器刷新时间，并且会产生不安全的部署(一般已损坏的文件)

，如果服务器支持热重载(Tomcat的Web应用程序中发生爆炸的 war )或至少了解文件系统修改(对于JBoss，在/ deploy中进行全面 war )

如果您需要先停止服务器，...

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

问答/验收/生产环境

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

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

我希望我足够清楚。

问候。