Tizen开发工作机制

1 系统简介

源代码管理(SCM)系统包含以下两部分:

源代码管理(SCM)系统包含以下两部分:

  • Git. 一款强大,灵活而且低成本的版本控制系统,可以让协同开发高效而稳定。 更多内容,请参考以下链接:

    -Git Community Book

    -Git Wiki

    -Git Manual Page

  • Gerrit. 一款基于web的代码审查系统,对那些使用Git进行版本控制的项目,使得代码在线审查更加方便。 通过对比(side-by-side)显示区别,内嵌批注(inline comments),Gerrit优化了代码审查流程并提高了审查质量。 此外,通过允许授权的用户将更改提交到Git仓库,Gerrit简化了基于Git的项目维护,即只使用Git进行项目维护。

1.2 OBS

开放式编译服务(OBS)是一个开放的,完整的发行版开发平台,为开发人员能够轻松地创建和发布基于不同硬件架构的各种Linux发行版的开源软件提供基础设施。 此外,OBS提供了一个协作环境,使开发者群体能够建立和提交更改到其他项目。

更过内容,请参考以下链接:

工作机制

一个给定的基于Git的项目有两个可能的分支:主分支和上游分支。

:主分支是强制性的,而上游分支是可选的。 更细节的原因,请参考以下相关内容。

  • 主分支(强制的)

Git在初始化仓库的时候就创建了主分支(一般作为开发分支),因此仓库中的默认分支是主分支,大部分开发者保证主分支是稳定而且可靠的开发路线。

也就是说,主分支需要保存项目的全部源代码树(比如C/C++,.h,makefile等文件),包括上游来源和本地的更改。 虽然主分支可以被重命名甚至可以被删掉,但是最好还是遵从强制性原则保留主分支。

:开发者需要在Git仓库的/packaging目录下维护软件包的版本历史。

  • 上游分支(可选的)

如果有两个仓库,其中一个仓库克隆自另一个仓库,这个父仓库通常被称为“上游”。

“上游分支”也是相同的概念。 不同的是,一个被称为“上游分支”的父分支是基于开发者的Git项目的。 在以下情况中上游分支是可选的:

  • 该项目只涉及来自Tizen纯原生代码,没有依赖上游项目。
  • 该项目不需要跟踪上游项目的最新更新。

2.1安装包的产生

将代码从源代码仓库中提交到OBS上后,会按照所需的格式生成安装包,如下图所示。

2.2安装包的开发工作流

安装包的开发工作流遵循下图所示的过程:

  1. 开发者搭建开发环境并安装开发工具。

  2. 开发者克隆源代码,按需进行开发,通过本地编译进行验证。

  3. 开发者提交补丁到Gerrit让相关人员进行代码审查。

  4. Tizen后端服务和审查者分别对所提交的代码补丁进行自动和手动的测试,然后再根据代码补丁质量进行打分,-1,0或者+1。

    • 自动测试:Tizen后端服务器会自动将补丁提交到OBS上进行编译和执行,然后OBS会反馈测试结果到Gerrit。
    • 手动测试:测试人员手动验证补丁然后再在Gerrit上发表意见。
  5. 维护人员在通过验证(验证+1)后批准该补丁(代码审查+2),然后合并本次代码变更到Gerrit仓库。

  6. 维护人员或者开发者通过gbs submit命令将软件包提交到OBS。

    :最好的做法是每个Tizen项目都有一个维护者,只要所有的补丁被合并维护者就应该立即将软件包提交到OBS进行编译,这样可以防止遗漏的情况发生。

  7. Tizen后端服务会同时激活预发布和正常发布的处理。 在预发行的处理过程中,创建的包含指定安装包的Tizen镜像会被提交给发行工程师进行审查。

  8. 发行工程师会根据安装包的质量接受或者拒绝该次提交。 对于接受的提交,对应的源代码会合并到OBS仓库中,同时,发行处理会接管并发布包含相关提交的Tizen镜像。

2.3角色和职责的分配

2.3.1开发者

开发者的职责是:

  • 编写和提交源代码到Git仓库的开发分支。
  • 为任何项目的任何分支进行验证和审查(“+1”或者“-1”进行打分)源代码的变更。

2.3.2维护者

维护者的职责是:

  • 在profile项目中创建其他分支,比如上游,开发分支。
  • 合并主分支到上游分支。
  • 审查代码,接受(打分“+2”)或者拒绝(打分“-2”)补丁。

维护者的准则是:

  • 维护者不应该不通过审查就接受自己的代码提交。
  • 为了处理代码的rebase操作,维护者有强制推送的权限。 维护者不能滥用权限去隐藏本来应该被审查的补丁的提交。

2.3.3审查者

审查者的职责是:

  • 审查代码,接受(打分“+2”)或者拒绝(打分“-2”)补丁。

2.3.4发行工程师

发行工程师的职责是:

  • 批准OBS上的提交。
  • 执行结果测试,然后转到发布区,让QA工程师执行进一步测试。

2.3.5QA工程师

QA工程师的职责是:

  • 对镜像进行充分的集成和验证,排除错误。