Maven 学习总结 (六) 之 版本

版本管理

  版本管理是指项目整体版本的演变过程管理。版本控制是指借助版本控制工具(如Subversion)追踪代码的每一个变更。

为了方便团队合作,项目开发过程中,大家应该使用快照版本,快照版本机制促进团队内部的交流,但是当项目需要对外发布时,我们显然需要提供非常稳定的版本,

使用该版本应当永远只能定位到唯一的构件,而不是像快照版本那样,定位的构件随时可能发生变化。我们称这类稳定的版本为发布版。项目发布了一个版本之后,就

进入下一个开发阶段,项目也就自然转到新的快照版本中。

  版本管理关心的问题之一就是这种快照版和发布版之间的转换。项目经过了一段时间的 x.0-SNAPSHOT开发之后,在某个时刻发布了x.0正式版,

然后项目进入了x.1-SNAPSHOT的开发。

  Maven 学习总结 (六) 之 版本

理想的发布版本应当对应了项目某个时刻比较稳定的状态,这包括源代码的状态以及构建状态,因此这个时候项目的构建应当满足以下的条件:

  - 自动化测试应当全部通过

  - 项目没有配置任何快照版本的依赖

  - 项目没有配置任何快照版本的插件

  - 项目所包含的代码已经全部提交到版本控制体系中

版本控制系统记录了代码的每个变化,通常这些变化都被维护在主干(Trunk)中,当项目发布的时候,开发人员应该使用标签记录这一特殊时刻的状态,

这样可以明确将某个源码版本从主干中标记出来,放到单独的位置,这样在之后的任何时刻,我们都能够快速地得到版本的源代码,从而能够比较各个版本

的差异,甚至重新构建一个同样版本的构建。

  Maven的版本号定义约定是这样的:

    <主版本>.<次版本>.<增量版本>-<里程碑版本>

  - 主版本,表示了项目的重大架构变更。

  - 次版本, 表示较大范围的功能增加和变化,及Bug修复。

  - 增量版本, 一般表示重大Bug的修复。

  - 里程碑版本, 这往往指某一个版本的里程碑。例如,Maven3已经发布了很多里程碑版本,如 3.0-alpha-1等。这样的版本与正式的3.0相比,往往表示不是非常稳定,

   还要更多测试。

主干、标签与分支,使用版本控制工具时我们都会遇到主干(trunk)、标签(tag)和branch(分支)的概念。

  - 主干,项目开发代码的主体,是从项目开始直到当前都处于活动的状态。从这里可以获得项目最新的源代码以及几乎所有的变更历史。

  - 分支, 从主干的某个点分离出来的代码拷贝,通常可以在不影响主干的前提下在这里进行重大Bug的修复,或者做一些实验性质的开发。如果分支达到了预期的目的

      通常发生在这里的变更会被合并(merge)到主干中。

  - 标签, 用来标识主干或者分支的某个点的状态,以代表项目的某个稳定状态,通常是版本的发布时状态。

使用maven管理项目版本的时候,涉及了很多版本控制系统操作,下面的例子介绍这些操作如何执行。该图展示的是一个典型的项目版本变化过程。

Maven 学习总结 (六) 之 版本

自动化版本发布,当熟悉了版本发布流程之后,就会希望借助工具将这一流程自动化,Maven Release Plugin提供了这样的功能,只要提供一些必要的信息,它就能

帮我们完成上述所有版本发布所涉及的操作。

Maven Release Plugin主要由三个目标,他们分别为:

  - release:prepare  准备版本发布,依次执行下列操作

    检查项目是否有未提交的代码

    检查项目是否有快照版本依赖

    根据用户的输入将快照版本升级为发布版本

    将POM中的SCM信息更新为标签地址

    基于修改后的POM执行Maven构建

    提交POM变更

    基于用户输入为代码打标签

    将代码从发布版升级为新的快照版

    提交POM变更

  - release : rollback 回退release : prepare所执行的操作。将POM回退至release: prepare之前的状态,并提交。需要注意的是,该步骤不会删除release:prepare生成的标签,

    因此用户需要手动删除。

  - release: perform 执行版本发布。签出release: prepare生成的标签中的源代码,并在此基础上执行mvn deploy命令打包并部署构件至仓库。

要为项目发布版本,首先需要为其添加正确的版本控制系统信息,这是因为maven release plugin需要知道版本控制系统的主干、标签等地址信息后才能执行相关的操作。

一般项目配置信息代码如下图:

Maven 学习总结 (六) 之 版本

connection表示一个只读的scm地址,developerConnection元素表示可写的scm地址,url则表示可以在浏览器中访问的scm地址。为了能让Maven识别,connection和developerConnection

必须以scm开头,冒号之后的部分表示版本控制工具的类型。该配置只告诉Maven当前代码的位置(主干),而版本发布还要涉及标签操作。还需要配置Maven Release Plugin告诉其标签基础

目录,如图:

             Maven 学习总结 (六) 之 版本

一切就绪之后运行命令:$mvn release:prepare , Maven Release Plugin开始准备发布版本,如果检测到项目有未提交代码,或者有快照版本的依赖,则会提示出错。如果没有问题,则会提示

用户输入想要发布的版本号、标签的名称以及新的快照版本号。

  如果项目的artifactId为app,发布前版本为1.0.0-SNAPSHOT,则Maven Release Plugin会提示使用发布版本号1.0.0,使用标签名app-1.0.0,新的开发版本为1.0.0-SNAPSHOT。如果这些

值是你想要的直接按ENTER,否则填入想要值按ENTER。

  基于这些信息,Maven Release Plugin会将版本从1.0.0-SNAPSHOT更新为1.0.0,并更新SCM地址http://192.168.1.103/app/trunk至http://192.168.1.103/app/tags/tag/app-1.0.0.并运行一

次Maven防止意外的错误出现,然后提交变化。为该版本打上标签。标签地址是http://192.168.1.103/app/tags/app-1.0.0。即tagBase路径加上标签名称。之后,Maven Release Plugin将POM

中的版本信息1.0.0升级到1.1.0-SNAPSHOT并提交。

  到此,release:prepare工作完成。如果这是发现一些问题,可以使用release:rollback命令回退发布,Maven Release Plugin会将POM的配置回退到release:prepare之前的状态。

  多个模块项目中执行release:prepare的时候,默认maven-release-plugin会提示用户设定每个模块发布版本号及新的开发版本号。

  如果检查release:prepare结果没有问题,标签和新的发布版本都是正确的,可以执行$mvn release:perfom, 该命令将标签中的代码签出执行mvn deploy命令构建版本,并部署到仓库中。

自动化构建分支,在正式发布版本1.0.0的同时,还可以穿件一个分支来修复将来这个版本可能遇到的中大的Bug。这个过程可以手动完成,如使用svn copy操作将主干代码复制到一个名为

1.1.x的分支中,然后修改分支中的POM文件,升级其版本为1.1.1-SNAPSHOT,这会设计很多操作。

  使用Maven Release Plugin的branch目标,它能帮我们自动化这些过程:

  - 检查本地有无未提交的代码

  - 为分支更改POM的版本,例如从11.0-SNAPSHOT改成1.1.1-SNAPSHOT

  - 将POM中的SCM信息改为分支地址

  - 提交以上更改

  - 将主干的代码复制到分支中

  - 修改本地代码使其回退到分支之前的版本

  - 提交本地更改

为了让Maven Release Plugin正常工作,和版本发布一样,必须在POM中提供正确的SCM信息。此外由于分支操作会涉及版本控制系统里的分支地址,因此还要为其配置分支基础目录。

                        Maven 学习总结 (六) 之 版本

  然而tagBase和branchBase并非是一定要配置的。如果为版本控制仓库使用了标准的布局,即在平行的trunk/tags/branches目录下分别放置项目主干代码、标签代码和

分支代码。那么Maven Release Plugin就能够自动根据主干代码位置计算出标签及分支代码的位置,因此你就可以省略这两项配置。

    Maven 学习总结 (六) 之 版本

上一篇:C#基础精华03(常用类库StringBuilder,List泛型集合,Dictionary 键值对集合,装箱拆箱)


下一篇:Android——4.2.2 源代码文件夹结构分析