导读:在实际项目开发中通常使用Maven来管理项目并采用模块化开发提高效率,即一个大型软件划分为多个模块且由多个团队共同开发。在这种开发模式下,模块与模块之间会存在依赖关系,如project-finance财务模块做为底层服务,project-trade交易模块作为上游会依赖于project-finance。那么可能出现的情况是财务团队正在进行快速进行项目改进或bug修复,并且更新发布库到远程仓库频率很高(如: project-finance1.1.0、project-finance2.0.0等),现在如果财务团队每隔一天上传一个新版本,那么将会出现以下场景:财务团队每次发布更新的代码时都要告知交易团队,然后交易团队需要手动更新pom.xml 文件里的project-finance至新版本号后拉取最新代码,过程相对比较麻烦。
1、快照概念
为了解决上述的问题,便引出了本文所要提及到的“快照”概念。快照是一种特殊的版本,指定了某个当前的开发进度的副本。与常规的版本不同之处在Maven每次构建都会在远程仓库中检查新的快照。
2、发布快照相比于发布新版本带来什么好处?
发布新版本方式 <dependency>
<groupId>project-finance</groupId>
<artifactId>project-finance</artifactId>
<version>1.0.0</version>
<scope>test</scope>
</dependency>
快照版本和正式版本的主要区别在于,本地获取这些依赖的机制有所不同。假设project-trade模块依赖一个project-finance:1.0.0版本,构建的时候构建工具会先在本地仓库中查找是否已经有了这个依赖库,如果没有的话才会去远程仓库中去拉取。所以假设财务团队发布了project-finance-1.0.0.jar到了远程仓库,有一个project-trade项目依赖了这个库,它第一次构建的时候会把该库从远程仓库中下载到本地仓库缓存,以后再次构建都不会去访问远程仓库了。所以如果财务团队修改了代码,向远程仓库中发布了新的软件包,但仍然叫project-finance-1.0.0.jar,那么依赖这个库的project-trad项目就无法得到最新更新。只有在重新发布的时候升级版本,比如叫做project-finance-1.1.0.jar,然后通知交易项目组也修改依赖版本为project-finance-1.1.0.jar,这样才能获取最新的代码。
使用快照的方式 <dependency>
<groupId>project-finance</groupId>
<artifactId>project-finance</artifactId>
<version>1.0.0-SNAPSHOT</version>
<scope>test</scope>
</dependency>
财务团队发布更新代码的快照到远程仓库中(project-finance:1.0-SNAPSHOT),新的快照会替代旧的快照包,同时交易团队修改pom.xml如上所示。由于Maven每次构建都会在远程仓库中检查新的快照并自动获取最新的快照,这样交易团队无需收到财务团队更新通知与手动修改版本号等就可以通过构建获取最新的project-finance代码,这样便解决获取最新代码过程繁杂的问题。
3、打快照版本包的方式
通过配置使用nexus管理SNAPSHOT包和RELEASE包可以解决各项目依赖本地的多变的包时的麻烦。在项目pom.xml配置文件中指定的版本号带有-SNAPSHOT后缀,如project-finance-1.0.0-SNAPSHOT
那么打出的包就是一个快照版本,将快照版本上传至nexus私服,之后迭代更新由同版本新快照替换旧快照。
4、最后
在模块化开发模式下,团队可以通过迭代发布SNAPSHOT版本,以便让其它项目能实时获取最新包做联调。当版本趋于稳定时(前提:确保当前项目的依赖项中不包含对任何SNAPSHOT版本的依赖,保证RELEASE版本的稳定性)发布一个RELEASE版本供正式使用。