jenkins集成自动化部署插件(一) deploy-plugin

本文介绍了如何使用Jenkins的deploy插件实现Web项目的自动化部署,包括配置Tomcat和JBoss的管理用户,以及通过Jenkins自动构建并部署war包的过程。

       前面简单熟悉了jenkins的job创建,并成功的运行了一个job,在实际情况中项目构建成功,特别是web项目构建成功是需要将war放到对应的服务上面,进行运行(测试的阶段可能就是发布到测试服务器上面)这样只需要指定构建的触发策略就可以自动构建以及部署,省去不少人工的成本,且不易出错,下面介绍的这个插件就是干这个。

       插件:deploy-plugin

       插件wiki地址:https://wiki.jenkins-ci.org/display/JENKINS/Deploy+Plugin

       安装方法:

       进入系统管理-插件管理,点击可选插件搜索deploy,找到插件后安装即可,安装成功后在已安装里面可以看到,不过名字可能会变了,如下图



 

       安装好后,新建的job或者已有的job都可以配置使用,配置如下图

      a、tomcat(使用的是tomcat6)

            首先需要配置好tomcat的管理用户,我们需要一个tomcat的管理员权限的用户,修改TOMCAT_HOME\config\tomcat-use.xml如下:



 

            启动tomcat。

            然后,修改jenkins中对应的job进行配置加入远程部署,填写要发布的war的目录、tomcat的访问地址以及管理员的帐号和密码,如下图



 

            然后立即构建即可。

          注意:经过后来测试,修改了java类后重新build后在部署到tomcat中是有效果的。

      b、jboss(使用的jboss4)

          和tomcat类似,需要配置好jboss的管理用户,jboss默认应该是admin admin,配置文件目录JBOSS_HOME\server\default\conf\props\jxm-console-users.properties

          配置好后(或者不配置就是用的默认的admin admin)启动jboss。 

          修改jenkins中job的配置,填写发表的war的目录、jboss的访问地址和用户帐号密码,如下图

        

 

          立即构建即可,在通过jboss访问看是否有成功

          注意:在测试jboss的时候开始每次都失败,jenkins提示的错误是http status 500 对应的war找不到,很是莫名其妙,开始还怀疑是不是war上传被拦截没上传成功,后查看jboss的log后发现是由于发布的war里面的jar和jboss自动的jar冲突导致项目部署失败,其实就是常见的项目在tomcat运行成功在jboss下启动不成功的问题,但是jenkins输出控制台输出的日志不太准确,所以最好参考远程部署服务器jboss的日志。

         可以看到自动化部署就是将构建生产的war调用服务器提供的接口进行部署,当然这里只是一个简单的例子,实际操作中可能会遇到其他问题,比如部署在服务器的时候需要修改相关配置参数等,这些细节问题,当然也是有对应的方法进行处理的,比如使用maven的构建命令参数,修改输出文件的配置参数,或者在构建成功后运行相关脚本或者插件对war里的配置文件修改等。

<think> 嗯,用户这次询问的是maven-deploy-plugin的介绍,结合之前的flatten-maven-plugin讨论,看来是在系统学习Maven的部署机制。用户可能正在搭建企业级CI/CD流程,需要深入理解这两个插件的协作关系。 注意到用户引用了站内资料[^4]提到版本管理的痛点,这正好解释了为什么需要结合flatten插件使用。用户似乎对微服务架构下的版本管理特别关注,之前提到的“所有服务依赖个版本管理包”的实践可能正是ta当前项目的架构方式。 在准备回答时,要特别强调三个关键点:deploy-plugin如何解决传统部署的痛点;二是它与flatten插件的互补关系(flatten处理POM,deploy负责传输);三是实际配置中的注意事项,比如跳过部署的场景配置。 用户提供的引用[^2][^3]特别提到了skip配置的示例,说明ta可能遇到过部署冲突的问题。这需要在回答中专门说明——当子模块不需要独立部署时,这个配置能避免重复部署错误。 考虑到用户技术背景较深,可以加入部署流程的时序说明,但要用mermaid简化表达。同时必须区分deploy和install的本质差异,这是很多开发者容易混淆的点。 最后生成的参考问题要延续版本管理主题,特别是CI集成和SNAPSHOT处理这类实用场景,这符合用户之前表现出的技术关切点。 </think>以下是关于 `maven-deploy-plugin` 的详细介绍,结合其在 Maven 生态中的核心作用和工作原理: --- ### 、核心作用 `maven-deploy-plugin` 是 Maven 官方提供的**部署插件**,主要功能是将构建生成的构件(JAR/WAR/POM 等)发布到**远程仓库**(如 Nexus/Artifactory 或 Maven Central)。它与 `maven-install-plugin` 形成互补: - `install-plugin`:将构件安装到**本地仓库**(`~/.m2/repository`) - `deploy-plugin`:将构件推送到**远程仓库**(供团队或公共使用) --- ### 二、核心 Goals 详解 | Goal 名称 | 作用 | 适用场景 | |---------------------|----------------------------------------------------------------------|------------------------------| | `deploy:deploy` | 部署整个项目及其所有构件(含 POM 文件)到远程仓库 | 标准 Maven 项目部署 | | `deploy:deploy-file` | 部署单个文件(如第三方 JAR)到远程仓库 | 非 Maven 构建的依赖部署 | --- ### 三、典型配置示例 #### 1. 基础配置(pom.xml) ```xml <build> <plugins> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-deploy-plugin</artifactId> <version>3.1.1</version> <!-- 最新稳定版 --> </plugin> </plugins> </build> ``` #### 2. 跳过部署的特殊场景 当子模块不需要独立部署时(如聚合模块),可通过 `skip` 配置跳过: ```xml <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-deploy-plugin</artifactId> <version>3.1.1</version> <configuration> <skip>true</skip> <!-- 关键配置:跳过当前模块部署 --> </configuration> </plugin> ``` *注:此配置常见于父 POM 或聚合模块[^2][^3]* --- ### 四、与 flatten-maven-plugin 的协作流程 在 CI-Friendly 项目中,两者配合实现安全部署: ```mermaid sequenceDiagram participant M as Maven Build participant F as flatten-maven-plugin participant D as deploy-plugin participant R as Remote Repo M->>F: 1. 执行 flatten (替换${revision}) F->>M: 生成扁平化POM M->>D: 2. 调用 deploy:deploy D->>R: 推送构件+扁平化POM ``` 1. **扁平化阶段**:`flatten-maven-plugin` 将动态版本(如 `${revision}`)替换为实际值[^4] 2. **部署阶段**:`deploy-plugin` 推送最终构件到远程仓库 --- ### 五、关键部署流程解析 #### 1. 标准部署命令 ```bash mvn clean deploy -Drevision=1.0.0 # 动态版本需通过参数传入 ``` #### 2. 认证配置(settings.xml) 远程仓库需配置认证信息: ```xml <servers> <server> <id>my-repo</id> <!-- 与pom.xml中distributionManagement的id匹配 --> <username>deploy-user</username> <password>{加密密码}</password> </server> </servers> ``` #### 3. 仓库定义(pom.xml) 指定部署位置: ```xml <distributionManagement> <repository> <id>my-repo</id> <url>https://repo.example.com/repository/maven-releases</url> </repository> <snapshotRepository> <id>my-repo</id> <url>https://repo.example.com/repository/maven-snapshots</url> </snapshotRepository> </distributionManagement> ``` --- ### 六、常见问题解决 | 问题现象 | 原因分析 | 解决方案 | |-----------------------------------|--------------------------|------------------------------------------| | 401 Unauthorized | 仓库认证失败 | 检查 settings.xml 的 server 配置 | | 部署后依赖解析失败 | POM 中残留动态版本占位符 | 确认 flatten-maven-plugin 已正确执行 | | "Skipping artifact deployment" | 配置了 `<skip>true</skip>` | 检查是否需移除 skip 配置[^2][^3] | | 重复部署冲突 | 相同版本重复推送 | 使用 `-DuniqueVersion=false` 覆盖部署 | --- ### 七、与 CI/CD 的集成 在 Jenkins/GitLab CI 中的典型配置: ```yaml # Jenkins Pipeline 示例 pipeline { environment { REVISION = sh(script: 'git rev-parse --short HEAD', returnStdout: true).trim() } stages { stage('Deploy') { steps { sh 'mvn clean deploy -Drevision=1.0.0-${REVISION}' } } } } ``` *通过结合 Git 提交哈希生成唯版本[^4]* --- ### 八、技术原理 部署过程的核心操作: 1. **构件准备**:收集 target/ 目录下的 JAR/WAR/POM 2. **元数据生成**:创建 `maven-metadata.xml` 3. **传输协议**:默认使用 HTTP/HTTPS 4. **仓库规则**: - SNAPSHOT 版本可重复覆盖 - RELEASE 版本禁止修改(需升级版本号) ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值