我们都知道Maven 支持两种版本发布 snapshot 和release。 我们在开发的时候都是使用snapshot 版本, 如果有里程碑发布就走release 版本。 但是项目中如果用到持续集成的话,我们真的还有必要使用snapshot 吗? 项目中涉及到 DEV, SIT, UAT, PREPROD 和 PROD 这N个不同的环境。 我们的的想法是build 出来的war 包能够先有开发人员在DEV 环境下自我验证通过, 然后相同的文件提交给 QA 来在SIT 环境下做集成测试。如果在SIT环境通过进一步提交相同的文件到UAT 环境做用户接受测试。 这里想要强调的重点是我们需要保持相同的文件。
刚开始我们的做法是在不同的环境都是重新build 出war 包 再运行deploy job。 这样的风险在于重新build 的文件可能跟开始测试的环境下的war 是不一样的。 我们知道svn 下的revision 版本号在同一个仓库中是唯一的。 如果我们能将revision 作为 jar 或者 war 的文件的名一部分,就能保证版本的唯一。
在parent pom 文件中 定义
<version>1.2.0-SNAPSHOT</version>
<properties>
<usecase.version>1.2.0</usecase.version>
<revision>SNAPSHOT</revision>
</properties>
在各个module 的pom 文件中 我们
<version>${usecase.version}-${revision}</version>
<parent> <version>1.2.0-SNAPSHOT</version></parent>
这里其实利用的Maven的child module 可以使用parent pom 中的properties。虽然maven 会给出一个warning说
<version>${usecase.version}-${revision}</version> 最好使用static 量。 我们可以在maven build 的时候通过 -Drevision 来指定svn 的版本号。 这样build 出来的 jar 文件就会形如
myapp-1.2.0-13645.jar
13645 就是 svn的版本号。 我们在Jenkins 中可以利用它的内建系统变量SVN_REVISION来获取revision 比如 -Drevision=${SVN_REVISION}, 这样build 出来的 jar 或者 war 都是 带svn 版本号而不是SNAPSHOT。 当然如果我们不传入这个revision系统变量,build 出来的就是默认的SNAPSHOT。
在Jenkins 中, 我们就不需要deploy 到 nexus 中了, 我们现在的做法是所有build 出来的war 都是通过 scp 插件拷贝到另外一台有比较大空间的server 来备份所有build 出来的war。 这样在后来的发布的job 都需要通过image name 参数指定 war包的文件名。 deploy job 会在这个备份的目录中找到需要deploy的war 文件将它拷贝到相应的tomcat 目录下。
这样做的另外一个好处是 以前有N多的deploy job 现在就简化成一个。 我们只需要一个带3个参数的job:
image name 指定 war 文件名
app 这个可以通过选择来指定我们的六个应用之一。
env 来指定deploy 的环境之一 : DEV, SIT 或者 PREPROD。
要知道以前我们的deploy 需要悲催的 几十个job, 在Jenkins 的job 列表中需要密密麻麻的 一坨。
另外需要说明的是采用了 <version>${usecase.version}-${revision}</version> 的pom 如果有间接依赖。间接依赖的包还是被用的是SNAPSHOT 版本, 我们需要消除这种间接依赖。
比如在我们的 inbound 的pom 中 我们依赖 inbound , inbound 会依赖 usecase-common jar。 这个时候我们发现 最终打出的war 里面包含的 usecase-common 不是 usecase-common-1.2.0-13645.jar , 而是 usecase-common-1.2.0- 加上一长串 timestamp 串, 明显是maven的snapshot过来的。 我们可以通过在inbound war的pom 文件中显示的 依赖 usecase-common 就可以解决这个问题。
分享到:
相关推荐
在Java开发中,Maven和Jenkins的结合使用能实现高效的持续集成。当开发人员将代码提交到SVN仓库后,Jenkins可以通过监听SVN的钩子(hook)自动触发Maven的构建过程。Maven负责编译代码,运行单元测试,打包应用,...
在现代软件开发流程中,持续集成(Continuous Integration,...然而,面对日益复杂的软件项目和持续增长的安全威胁,持续集成架构的设计与实施仍面临着诸多挑战,需要团队不断学习和探索,以适应快速变化的技术环境。
本教程将详细介绍如何利用Maven、Nexus、Jenkins和Subversion(SVN)搭建一个完整的持续集成环境。 1. Maven3 安装 Maven是一个项目管理和综合工具,它管理项目依赖关系,构建生命周期,以及项目信息。以下为安装...
这个流程通常涉及到Jenkins持续集成工具、Maven构建管理工具、Subversion(svn)版本控制系统以及Wildfly应用服务器的集成。下面将详细介绍如何配置和使用这些工具来实现自动化发布。 1. **安装Jenkins** Jenkins...
### GitLab + Jenkins + SonarQube 敏捷开发持续集成环境 #### 一、敏捷宣言与持续集成 ...通过上述步骤,可以构建一个基于 GitLab、Jenkins 和 SonarQube 的敏捷开发持续集成环境,提高软件项目的开发效率和质量。
由于Android Maven插件与Maven生态系统兼容,因此很容易与Jenkins、Travis CI等持续集成工具集成,实现自动化构建、测试和部署。 **六、注意事项** - 要确保你的Maven本地仓库已经包含了所有Android库的依赖,否则...
7. **持续集成与部署**:在分布式环境中,持续集成(CI)和持续部署(CD)是必要的。Maven可以与Jenkins、GitLab CI/CD等工具结合,实现自动化构建、测试和部署,确保快速反馈和稳定运行。 8. **分布式配置管理**:...
总结来说,Jenkins是一个强大的持续集成和持续交付工具,通过下载并部署`jenkins.war`文件,你可以轻松地在你的服务器上建立一个自动化构建和部署的环境。结合各种插件和配置,Jenkins能适应各种复杂的开发场景,...
- `<ciManagement>`:持续集成服务器的配置,如Jenkins。 - `<mailingLists>`:项目相关的邮件列表信息。 - `<prerequisites>`:构建项目所需的最低Maven版本或其他工具。 8. **仓库管理**: - `<repositories>...
它使得Java项目的持续集成和持续部署(CI/CD)流程更加顺畅,是现代化软件开发不可或缺的工具之一。尽管git-release-maven-plugin功能相对简单,但它为那些希望快速、可靠地发布软件的团队提供了便利。在实际开发...
8. **持续集成/持续部署(CI/CD)**:在大型项目中,Maven常与CI/CD工具(如Jenkins、GitLab CI/CD)结合使用,实现自动化构建和部署,确保代码质量并加速开发流程。 综上所述,"yongyou NCC 人力模块所需 Maven 库...
批处理文件可以方便地整合这些操作,并且可以通过Jenkins、GitLab CI/CD或其他持续集成工具自动化执行,从而实现一键升级和部署。 总之,Maven自动升级版本号并打包上传的脚本是提高开发效率的有效手段,它减少了...
6. **持续集成/持续部署(CI/CD)中的权限**:在持续集成和持续部署流程中,权限管理确保只有经过授权的更改才能触发构建和部署。这通常涉及到Git等版本控制系统中的权限配置,以及CI服务器如Jenkins或GitLab CI的权限...
6. **持续集成**:与持续集成工具如Jenkins、Travis CI等结合,自动化构建和测试流程。 通过以上介绍,我们可以看到Maven 3.6.0在项目管理和构建效率方面有着显著优势,它简化了Java开发过程,提高了团队协作效率。...
- **JDK:**Java 开发工具包,用于支持 Maven 和 Jenkins 的运行。 - **Git:**版本控制系统,用于拉取代码。 - **Maven:**Java 项目的构建工具,用于代码的编译打包。 - **Tomcat:**Web 服务器,用于部署 Java ...
Jenkins是一款广受欢迎的开源软件项目,其主要功能在于实现持续集成和持续部署,从而确保软件开发过程的高效和稳定。这款工具的核心是基于Java语言编写,因此它具有跨平台特性,可以在包括Linux在内的多种操作系统上...
在IT行业中,持续集成(Continuous Integration, CI)是提升开发效率和代码质量的重要工具,其中Jenkins是最为广泛应用的CI服务器之一。而Subversion(SVN)是一种版本控制系统,常用于管理软件项目源代码。将...
安装到本地 Maven 仓库: mvn install 存储在~/.m2/repository 中 将 SNAPSHOT 版本部署到本地 Nexus 只有二进制: mvn deploy 二进制文件,包括 javadoc 和源文件: mvn deploy -P release 执行 RELEASE :...