为了在多个版本中并行开发,提高开发效率,保证各个版本和各个环境(开发、测试、主干)的独立,避免相互影响,减少最终发布时合并主干出现冲突的概率,降低冲突处理的难度,那么在团队开发过程中就需要一定的规范流程。

版本命名规范

软件版本号由四部分组成,第一个1为主版本号,第二个1为子版本号,第三个1为阶段版本号,第四部分为日期版本号加希腊字母版本号,希腊字母版本号共有5种,分别为:base、alpha、beta、RC、release。例如:1.1.1.051021_beta。

版本号修改规则

⑴ 主版本号(1)
当功能模块有较大的变动,比如增加多个模块或者整体架构发生变化。此版本号由项目决定是否修改。
⑵ 子版本号(1)
相对于主版本号而言,子版本号升级对应的是软件功能有一定的增加或变化,比如增加了对权限控制、增加自定义视图等功能。此版本号由项目决定是否修改。
⑶ 阶段版本号(1)
一般是 Bug 修复或是一些小的变动,要经常发布修订版,时间间隔不限,修复一个严重的bug即可发布一个修订版。此版本号由项目经理决定是否修改。
⑷ 日期版本号(051021)
用于记录修改项目的当前日期,每天对项目的修改都需要更改日期版本号。此版本号由开发人员决定是否修改。
⑸ 希腊字母版本号(beta)
此版本号用于标注当前版本的软件处于哪个开发阶段,当软件进入到另一个阶段时需要修改此版本号。此版本号由项目决定是否修改。

软件版本阶段说明

⑴ Base:
此版本表示该软件仅仅是一个假页面链接,通常包括所有的功能和页面布局,但是页面中的功能都没有做完整的实现,只是做为整体网站的一个基础架构。
⑵ α(Alpha)版:内测版。
软件的初级版本,表示该软件在此阶段以实现软件功能为主,通常只在软件开发者 内部交流,或者专业测试人员测试用,一般而言,该版本软件的Bug较多,需要继续修改,是测试版本。测试人员提交Bug经开发人员修改确认之后,发布到测试网址让测试人员测试,此时可将软件版本标注为alpha版。
⑶ β(Beta)版:公测版。
该版本相对于α版已有了很大的改进,消除了严重的错误,但还是存在着一些缺陷,需要经过多次测试来进一步消除,此版本主要的修改对像是软件的UI,供专业爱好者大规模测试用。
⑷ RC 版:
是 Release Candidate 的缩写,意思是发布倒计时,候选版本,该版本已经相当成熟了,完成全部功能并清除大部分的BUG,基本上不存在导致错误的BUG,与即将发行的正式版相差无几。
⑷ Release 版:
该版本意味“最终版本”,在前面版本的一系列测试版之后,终归会有一个正式版本,是最终交付用户使用的一个版本。该版本有时也称为标准版。一般情况下,Release不会以单词形式出现在软件封面上,取而代之的是符号(R)。

版本号修改举例说明

比如版本号为:1.0.0.0321_alpha ,此时为内部测试阶段
⑴ 开发人员修复了测试人员提交的bug并经测试人员测试验证关闭bug之后,发布到外网时,此时就进入了软件的下一个阶段,版本号可改为:1.0.0.0321_beta ,如当前日期跟上一个版本号的日期不一样,版本号可改为:1.0.0.0322_beta。
⑵ 如果修复了一些重大Bug 并按照流程发布到外网时就可发布一个修订版,如1.0.1.0322_beta,日期为发布的当前日期。
⑶ 如果对软件进行了一些功能上的改进或增强,进行了一些局部变动的时候要修改次版本号,如:1.1.0.0322_beta(上一级有变动时,下级要归零)。
⑷ 当功能模块有较大变动,增加模块或整体架构发生变化时要修改主版本号,如新增加了退款功能,则版本号要改为:2.0.0.0322_beta 。
⑸ 紧急情况:如果bug比较紧急可跳过一般流程,由开发人员尽快修复bug,测试确认之后直接发布该版本的beta版。

APK 文件命名

appName_版本号,即中间用“下划线”分割。

持续集成流程

引用自百科的话来说,持续集成是一种软件开发实践,即团队开发成员经常集成它们的工作,通过每个成员每天至少集成一次,也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建(包括编译,发布,自动化测试)来验证,从而尽早地发现集成错误。

项目自动化流程

在没有自动化的开发过程中,很多事就需要我们人为去做,那就增长我们的时间成本,而且难免会有疏忽的一些问题,比如某个配置文件忘改了,哪个版本出问题,代码的集成,重复构建等一些耗时且易于犯错的问题。

于是我们引入一些自动化的Java构建工具:

Apache Ant

Apache Ant,是一个将软件编译、测试、部署等步骤联系在一起加以自动化的一个工具,大多用于Java环境中的软件开发。由Apache软件基金会所提供。默认情况下,它的buildfile(XML文件)名为build.xml。每一个buildfile含有一个和至少一个预设的,这些targets包含许多task elements。每一个task element有一个用来被参考的id,此id必须是唯一的

build.xml 示例:

version="1.0" ?>
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
<project name="Hello World" default="execute">
<target name="init">
<mkdir dir="build/classes"/>
<mkdir dir="dist"/>
</target>
<target name="compile" depends="init">
<javac srcdir="src" destdir="build/classes"/>
</target>
<target name="compress" depends="compile">
<jar destfile="dist/HelloWorld.jar" basedir="build/classes" />
</target>
<target name="execute" depends="compile">
<java classname="HelloWorld" classpath="build/classes"/>
</target>
</project>

Apache Maven

Apache Maven,是一个软件(特别是Java软件)项目管理及自动构建工具,由Apache软件基金会所提供。基于项目对象模型(缩写:POM)概念,Maven利用一个中央信息片断能管理一个项目的构建、报告和文档等步骤。
Maven也可被用于构建和管理各种项目,例如C#,Ruby,Scala和其他语言编写的项目。Maven曾是Jakarta项目的子项目,现为由Apache软件基金会主持的独立Apache项目

Maven项目使用项目对象模型(Project Object Model,POM)来配置。
项目对象模型存储在名为 pom.xml 的文件中。
以下是一个简单的示例:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
<!-- model version is always 4.0.0 for Maven 2.x POMs -->
<modelVersion>4.0.0</modelVersion>
<!-- project coordinates, i.e. a group of values which
uniquely identify this project -->
<groupId>com.mycompany.app</groupId>
<artifactId>my-app</artifactId>
<version>1.0</version>
<!-- library dependencies -->
<dependencies>
<dependency>
<!-- coordinates of the required library -->
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>3.8.1</version>
<!-- this dependency is only used for running and compiling tests -->
<scope>test</scope>
</dependency>
</dependencies>
</project>

引自https://zh.wikipedia.org/wiki/Apache_Maven介绍

目前JavaEE使用Apache_Maven的比较多,而我们选择了Android Studio 内置的封装布署工具,拥有以上工具中优秀特性并且更棒的工具Gradle。

Gradle

Gradle是一个基于Apache Ant和Apache Maven概念的项目自动化建构工具。它使用一种基于Groovy的特定领域语言来声明项目设置,而不是传统的XML。[2]
当前其支持的语言限于Java、Groovy和Scala[3],计划未来将支持更多的语言。

使用 Gradle 的优势

•    自动处理包相依关系 - 取自 Maven Repos 的概念
•    自动处理布署问题 - 取自 Ant 的概念
•    条件判断写法直觉 - 使用 Groovy 语言

过去 Java 开发者常用 Maven 和 Ant 等工具进行封装布署的自动化,或是两者兼用,不过这两个包彼此有优缺点,如果频繁改变相依包版本,使用 Ant 相当麻烦,如果琐碎工作很多,Maven 功能不足,而且两者都使用 XML 描述,相当不利于设计 if、switch 等判段式,即使写了可读性也不佳,而 Gradle 改良了过去 Maven、Ant 带给开发者的问题,至今也成为 Android Studio 内置的封装布署工具。

代码检测流程

在我们日常开发过程中,使用静态代码检查工具自动进行代码检查,对软件开发者来讲是有利的事情,因为这些工具相比人工方式,能更快捷的查找软件存在的缺陷。但是,在很多情况下,这些工具并没用被开发者所广泛采用。

尽管在我们开发中编译和测试的结果给出了一些产品健康状态的基本报告,但没有提供代码质量的基本报告,也没有任何地方可以查看到我们开发代码质量,产品质量的趋势,来帮助我们发现问题提升产品质量,我们公司内部构建平台会对代码质量,产品质量做一些分析,来推进产品的前进。

代码覆盖率

在Java中有很多免费和商业的代码覆盖率工具,大多数这些工具都可以集成在我们的构建平台上。这里我们列举几个Gradle比较流行的代码覆盖率工具。

Cobertura

Cobertura 是一种开源工具,它通过检测基本的代码,并观察在测试包运行时执行了哪些代码和没有执行哪些代码,来测量测试覆盖率。除了找出未测试到的代码并发现 bug 外,Cobertura 还可以通过标记无用的、执行不到的代码来优化代码。

Emma

EMMA 是一个开源、面向 Java 程序测试覆盖率收集和报告工具。它通过对编译后的 Java 字节码文件进行插装,在测试执行过程中收集覆盖率信息,并通过支持多种报表格式对覆盖率结果进行展示。 EMMA 所使用的字节码插装不仅保证 EMMA 不会给源代码带来“脏代码”,还确保 EMMA 摆脱了源代码的束缚,这一特点使 EMMA 应用于功能测试成为了可能。

Clover

Clover是一款量度单元测试代码覆盖率(Code Coverage)的软件,用于检测Java单元测试是否完整覆盖代码中所有可能的路径,能够快速、准确地检测测试是否覆盖代码中的所有路径。

团队成员通过Code review来发现架构、逻辑设计方面、安全缺漏和一些潜在的bug,但随着项目业务的增长,Code review的过程难免也会疏忽很多潜在的bug等问题。

在我们工作中还有一些静态代码检查工具如CheckstyleFindbugsPMD等,将他们集成在我们的构建平台上,并成为我们构建流程中的一步骤。

开发流程

对于开发流程,在不同的项目团队中,开发流程不太一样,但大致可为:
每天下班前RD必须把今天工作代码全部提交到Git上。

####

  • 使用Jenkins CI ,每天定期会从Git上拉去最新代码,自定编译构建生成APK发出邮件,二维码等到产品维护人员的邮箱,并且将应用更新至公司内测分发平台。
  • 编译构建成功,进行自动化测试、单元测试覆盖率(Cobertura、Emma或Clover等生成)、功能测试结果(如Selenium)、静态代码检查结果(Checkstyle、Findbugs、PMD等)
  • 测试人员对产品进行test,测试中若有紧急问题也可以让开发人员可以随时修改提交代码。并且立即重新构建测试安装包。

打包和发布流程

以上版本管理发布流程只是参考指南,而不是具体规则。你可以根据自己实际情况来选择适合自己的版本管理发布流程或微调来满足自己的需要。