Maven实战读书笔记（14）

什么是版本管理？

版本管理是指项目整体版本的演变过程管理，如从1.0-SNAPSHOT到1.0再到1.1-SNAPSHOT

 

什么是版本控制？

版本控制是指借助版本控制工具（如Subversion）追踪代码的每一个变更

 

什么时候可以将快照版本更新为发布版本

1、所有自动化测试应当全部通过

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

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

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

 

Maven的版本号定义约束

可能有个版本号是这样的，1.3.4-beta-2

Maven的版本号定义约定是这样的，<主版本>.<次版本>.<增量版本>-<里程碑版本>

1、主版本：表示项目的重大架构变更

2、次版本：表示较大范围的功能增加和变化

3、增量版本：一般表示重大Bug的修复

4、里程碑版本：顾名思义，这往往指某一个版本的里程碑。例如，Maven 3已经发布了很多里程碑版本，如3.0-alpha-1、3.0-alpha-2、3.0-beta-1等，这样的版本与正式的3.0相比，往往表示不是非常稳定，还需要很多测试

 

关于版本号需要注意的地方

1、不是每个版本号都必须拥有这四个部分，一般来说，主版本和次版本都会声明，但增量版本和里程碑就不一定了

2、当用户在声明依赖或插件未声明版本时，Maven就会根据上述版本号约定自动解析最新版本。这个时候就需要对版本号进行排序，对于主版本、次版本和增量版本来说，比较是基于数字的，因此1.5>1.4>1.3.11>1.3.9。而对于里程碑版本，Maven则只进行简单的字符串比较，因此会得到1.2-beta-3>1.2-beta-11的结果

 

理解主干、标签与分支

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

2、分支：从主干的某个点分离出来的代码拷贝，通常可以在不影响主干的前提下在这里进行重大Bug的修复，或者做一些实验性质的开发。如果分支达到了预期的目的，通常发生在这里的变更会被合并(merge)到主干中

3、标签：用来标识主干或者分支的某个点的状态，以代表项目的某个稳定状态，这通常就是版本发布时的状态

 

使用Maven管理项目版本，可能有这样的场景

项目最初的版本是1.0.0-SNAPSHOT，经过一段时间的开发后，1.0.0版本发布，这个时候就需要打一个标签，图中用一个长条表示。然后项目进入1.1.0-SNAPSHOT状态，大量的开发工作都完成在主干中，添加了一些新特性并修复了很多Bug之后。项目1.1.0发布，同样，这时候需要打另一个标签。发布过后，项目进入1.2.0-SNAPSHOT阶段，可这个时候用户报告1.1.0版本有一个重大的Bug，需要尽快修复，我们不能在主干中修Bug，因为主干有太多的变化，无法在短时间内测试完毕并发布，我们也不能停止1.2.0-SNAPSHOT的开发，因此这时候可以基于1.1.0创建一个1.1.1-SNAPSHOT的分支，在这里进行Bug修复，然后为用户发布一个1.1.1增量版本，同时打上标签。当然，还不能忘了把Bug修复涉及的变更合并到1.2.0-SNAPSHOT的额主干中，主干在开发一段时间之后，发布1.2.0版本，然后进入到新版本1.3.0-SNAPSHOT的开发过程中

 

使用Maven Release Plugin插件，流程化管理版本发布

Maven Release Plugin主要有三个目标，它们分别为：

n         release：prepare，准备版本发布

n         release：rollback，回退release：prepare所执行的操作

n         release：perform，执行版本发布

 

release：perpare目标都做了哪些操作？

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

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

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

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

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

n         提交POM变更

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

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

n         提交POM变更

 

release：rollback目标都做了哪些操作？

将POM回退至release：prepare之前的状态，并提交。需要注意的是，该步骤不会删除release：prepare生成的标签，因此用户需要手动删除

 

release：perform目标都做了哪些操作？

签出release：prepare生成的标签中的源代码，并在此基础上执行mvn deploy命令打包并部署构件至仓库

 

另外，使用Maven Release Plugin插件需要注意

1、要为项目发布版本，首先需要为其添加正确的版本控制系统信息

2、这是因为Maven Release Plugin需要知道版本控制系统的主干、标签等地址信息后才能执行相关的操作

 

一般的SCM，版本发布配置SCM信息如下

<project>

...

       <scm>

              <connection>scm:svn:http://10.1.0.56/app/trunk</connection>

              <developerConnection>scm:svn:http://10.1.0.56/app/trunk</developerConnection>

              <url>http://10.1.0.56/account/trunk</url>

       </scm>
...

</project>

对上面配置进行说明

1、connection元素表示一个只读的scm地址

2、developerConnection元素表示可写的scm地址

3、url表示可以在浏览器中访问的scm地址

4、为了让Maven识别，connection和developerConnection必须以scm开头，冒号之后的部分表示版本控制工具类型（这里是svn），Maven还支持cvs、git等

5、接下来才是实际的scm

地址，该配置中的connection使用了http协议，而developerConnection则由于涉及写操作，使用https协议进行了保护

 

上面的配置只告诉Maven当前代码的位置（主干），而版本发布还要涉及标签等操作，因此，还需要配置Maven Release Plugin告诉其标签的基础目录

 

配置maven-release-plugin提供标签基础目录

<plugin>

       <groupId>org.apache.maven.plugins</groupId>

       <artifactId>maven-release-plugin</artifactId>

       <version>2.0</version>

       <configuration>

              <tagBase>http://10.1.0.56/app/tags/</tagBase>

       </configuration>

</plugin>

 

在执行release：prepare之前还有两个注意点

1、系统必须要提供svn命令行工具，Maven需要svn命令行工具执行相关操作，而无法使用图形化工具，如TortoiseSVN；

2、POM必须配置了可用的部署仓库，因为release：perform会执行deploy操作将构件发布到仓库中

 

maven-release-plugin提供autoVersionSubmodules参数

使用这个参数，maven-release-plugin会自动为所有子模块使用与父模块一致的发布版本和新的SNAPSHOT版本：

mvn release:prepare -DautoVersionSubmodules=true

 

如果使用release:prepare命令执行的结果没有问题，就执行mvn release:perform命令

这部分会出现很多问题！~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 

执行release:perform和release:branch命令以后再试

 

如何保障构件的安全性

当从中央仓库下载第三方构件的时候，你可能会想要验证这些文件的合法性，例如它们是由开源项目官方发布的，并且没有被篡改过，同样地，当发布自己项目给客户使用的时候，你的客户也会想要验证这些文件是否是由你的项目组发布的，且没有被恶意篡改过PGP (Pretty Good Privacy)就是这样一个用来帮助提高安全性的技术。PGP最常用来给电子邮件进行加密、解密以及提供签名，以提高点子邮件交流的安全性

 

基于PGP标准的GPG

GnuPG （简称GPG，来自http://www.gnupg.org/） 是PGP标准的一个免费实现，无论是类UNIX平台还是Windows平台，都可以使用它。GPG能够帮助我们为文件生成签名、管理密钥以及验证签名等

 

具体如何使用GnuPG以后用到再说吧