随着持续集成和持续交付的出现 ，我们的构建被分为不同的步骤，以创建部署管道。 这些步骤中的一些步骤可以是例如编译和运行快速测试，运行慢速测试，运行自动验收测试或发布应用程序等。

部署流程的最后步骤意味着将我们的产品（如果是JEE项目，则是战争或耳朵 ）部署到类似生产的环境，用于UAT或发布产品时部署到生产系统。
在本文中，我们将了解如何配置Jenkins来正确管理Java Enterprise Application的部署。

要做的就是创建应用程序，在这种情况下，在Java中一个非常简单的Web应用程序的第一件事情（其实只有一个JSP它打印一个Hello World！消息）和mavenize它来创建一个war文件（bar.war）时， 包目标已执行。

然后，我们需要创建一个Jenkins作业（称为bar-web ），该作业负责编译和运行单元测试。

完成此工作后，将进行其他工作，例如运行集成测试，运行更多测试，静态代码分析（即代码质量）或将工件上传到工件存储库，但此处不会显示。
最后，最后一步意味着将先前生成的代码部署到暂存环境（例如，用于运行用户验收测试 ），并在关键用户同意后将其部署到生产环境。
因此，让我们看看如何在Jenkins中创建这些最终步骤。 请注意，在所有这些步骤中都必须使用在先前步骤中创建的二进制文件（在本例中为bar-web ）。 这是因为两个原因，第一个是您的部署管道应尽可能快地运行，并且显然在每个步骤中编译代码并不是获得代码的最佳方法，第二个原因是每次您编译源代码时，增加了不被编译为先前步骤的来源的机会。 为了实现此目标，我们可以遵循两种策略，第一种是将二进制文件上传到工件存储库（例如Nexus或Artifactory ），然后在每个作业中从那里获取。 第二个是使用复制工件 Jenkins插件来获取上一步生成的二进制文件。

让我们看看如何为第一种方法配置Jenkins 。

使用工件存储库方法，要求您从存储库下载我们要部署的版本，然后将其部署到外部环境； 在我们的案例中，部署到Web服务器。 所有这些步骤都是通过使用maven-cargo-plugin完成的 。

<build><plugins><plugin><groupId>org.codehaus.cargo<groupId><artifactId>cargo-maven2-plugin<artifactId><version>1.0<version><!-- Container configuration --><container><containerId>tomcat6x<containerId><type>remote<type><container><configuration>          <type>runtime<type><properties><cargo.remote.username>admin<cargo.remote.username><cargo.remote.password><cargo.remote.password><cargo.tomcat.manager.url>http:localhost:8888manager<cargo.tomcat.manager.url><properties><configuration><deployer><deployables><deployable><groupId>com.lordofthejars.bar<groupId><artifactId>bar-web<artifactId><type>war<type><deployable><deployables><deployer><plugin><plugins><build><dependencies><dependency><groupId>com.lordofthejars.bar<groupId><artifactId>bar-web<artifactId><type>war<type><version>${target.version}<version><dependency><dependencies>

然后，我们只需要创建一个名为bar-to-staging的新Jenkins作业即可运行cargo：redeploy Maven目标，而Cargo插件将负责将bar-web部署到Web服务器。

这种方法具有一个优点和一个缺点。 主要优点是您不必局限于Jenkins ，可以单独使用Maven ，也可以使用任何其他支持Maven的 CI 。 主要缺点是依赖于artefacts存储库，此计划计划了一个新问题，部署管道涉及许多步骤，并且在这些步骤之间（通常，如果您正在构建快照版本），可以将新的artefact上传到具有相同版本的artefacts存储库，并在管道执行过程中使用它。 当然，可以通过在人工制品存储库中管理权限来避免这种情况。

另一种方法是使用Jenkins插件，称为copy-artifact-plugin 。 在这种情况下， Jenkins充当人工制品存储库，因此，在不涉及任何外部存储库的情况下，将在下一步中使用在上一步中创建的工件。 使用这种方法，我们不能使用maven-cargo-plugin ，但是可以将deploy-jenkins-plugin与copy-artifacts-plugin结合使用。

因此，让我们看看如何实现这种方法。

首先是创建一个Jenkins 构建作业 （ bar-web ），该作业将创建war文件。 请注意，定义了两个Post-build动作 ，第一个是Archive the artifacts ，用于存储生成的文件，因此复制工件插件可以将它们复制到另一个工作空间。 另一个是“ 构建其他项目” ，在这种情况下，该项目调用一个作业，该作业负责将war文件部署到暂存目录（ bar deploy-to-staging ）。

接下来是create bar deploy-to-staging构建作业，其主要操作是将先前构建作业生成的war文件部署到Tomcat服务器。

对于第二个构建作业，您应该配置复制工件插件以将以前生成的文件复制到当前工作空间，因此在“ 构建”部分的“ 从另一个项目复制工件”部分中，我们设置了要从哪个复制作业复制工件（在本例中） bar-web ）以及我们要复制的工件。 最后，在“构建后操作”部分中 ，我们必须配置应将哪个文件部署到Tomcat （ bar.web ），请记住该文件是以前的构建作业所编译和打包的，最后设置了Tomcat参数。 执行管道如下所示：

请注意，已添加了第三个构建作业 ，该作业将war文件部署到生产服务器。

第二种方法是第一种方法的对立部分，您可以确保在管道的上一步中使用的伪像将在所有步骤中使用，但是您必须遵守Jenkins / Hudson的规定 。

因此，如果您要在人工制品存储库中创建策略，以便只有管道执行程序可以将人工制品上载到存储库，则第一种方法更好，但是如果您不使用外部人工制品存储库（按原样使用Jenkins ），则第二种方法是最好的方法是确保先前步骤中包装的人工制品不会被并行步骤修改。

将文件部署到服务器后，可以毫无问题地执行验收测试或UAT测试。

我希望现在我们可以安全，更好地解决部署流程的最后步骤。

参考：在One Jar To Rulem All博客中，我们的JCG合作伙伴 Alex Soto 与Jenkins一起部署JEE工件 。