开发工作流的 Gluster

本文档提供详细的发展模式概述其次是 GlusterFS 项目。

基础知识

GlusterFS 发展模式很大程度上是围绕功能和 Git 版本控制系统，Gerrit 代码审查所提供的功能系统和詹金斯持续集成系统。它是底漆

项目的贡献。

# # Git

Git 是一种极其灵活的分布式版本控制系统。 GlusterFS 的主要一个 git 仓库会在 < http://git.gluster.org > 和公共镜子是在 GlusterForge (https://forge.gluster.org/glusterfs-core/glusterfs) 和在 GitHub (https://github.com/gluster/glusterfs)。主办发展回购

里面 Gerrit 和每个代码合并立即复制到公共镜子。

很好的入门 Git 可以发现在 < http://www-cs-students.stanford.edu/~blynn/gitmagic/ >。

# # Gerrit

Gerrit 是出色的代码审查制度与 git 开发基于工作流的头脑。GlusterFS 项目代码审查制度是

在 [review.gluster.org] (http://review.gluster.org) 主办。Gerrit 作品

关于"改变"s。变化是一组中的各类文件修改

您的存储库来完成一项任务。这是本质上是一个大的 git

提交与所有必要的更改，可以同时建立和测试。

审查进程部分后面所述 Gerrit 用法。

# # 詹金斯

詹金斯是一个持续集成构建系统。在主办了詹金斯

< http://build.gluster.org >。詹金斯被配置为使用由 Gerrit

设置挂钩。每个"改变"推向 Gerrit 是

被詹金斯，建自动拾取和烟雾测试。输出的

可以在查看所有的生成和测试 < http://build.gluster.org/job/smoke/ >。詹金斯也是与安装程序

'回归' 工作，旨在执行测试脚本作为提供更改代码的一部分。

准备安装程序

这里是一个初始的一次性步骤列表之前你可以开始黑客代码。

# # 注册

通过单击注册帐户在 < http://review.gluster.org > '注册' 右侧顶上。您可以使用您的 gmail 登录为

openID 身份。

# # 首选的电子邮件

在首次登录，将添加到您的身份的你 git/工作电子邮件。你会有

点击的 URL，并发送到您的电子邮件设置适当的全名称。确保您设置您的 git/工作电子邮件作为您首选的电子邮件。

这应该是从您的代码的所有提交的电子邮件地址相关联。

# # 设置用户名

选择您自己的用户名。

# # 看 glusterfs

在 Gerrit 设置观看 'glusterfs' 项目。在所有三个打勾

（新的变化，所有的评论，提交更改）类型的通知。

# # 电子邮件过滤器

设置筛选器规则在您的邮件客户端到标记或分类邮件标题

列表 Id:

作为邮件源自审查制度。

# # SSH 密钥

这样你就可以成功地进 Gerrit 提供您的 SSH 公钥访问开发 git 存储库，以及将更改为推审查/合并。

# # 克隆工作树

让自己工作树通过克隆的发展从存储库 Gerrit

sh$ git 克隆 ssh://[username)@]git.gluster.org/glusterfs.git glusterfs

分支的政策

这一节将介绍这两上公共回购, 的分支策略以及建议的最佳做法，为本地分支

# # 硕士/释放分支

在 glusterfs.git，主分支是向前发展的分支。这是新的功能与第一个的进来。事实上，这是在几乎

每次更改 (commit) 排名第一。始终保持主分支

在一种可生成状态和烟雾测试通过。

释放的火车（3.1.z、 3.2.z、 3.2.z）每个有源自一个分支大师。代码冻结的每个新版本火车标记由创作

释放 3.y 分支。在这一点上没有新功能被添加到

释放-3.y 分支。所有修补程序和提交第一次进入大师。

从那里，只有 bug 修复获取到相关版本 backported 分支机构。从释放 3.y 分支，实际释放代码快照

(例如 glusterfs-3.2.2 等。)标记 (git 注释标记与 ' git 标记

-') 运作为一个压缩文件。

# # 个人每任务分支

作为一种最佳做法，建议您执行所有的代码更改在工作树中的本地分支的任务。当地分支机构应

创建从上游分支打算提交更改。如果您正在提交对主分支更改，首先创建

像这样-本地任务分支

sh$ git 签出大师 sh$ git 分支 bug XYZ & & git 签出 bug XYZ ...< 黑客、提交 >

如果你是反向发布分支，或作新的变革的修复程序一个发布分支，您的命令会略有不同。如果你

签出一个在您当地工作树中的发布分支第一次，请确保将其设置为这样一个远程跟踪分支 -

sh$ git 结帐-b 释放 3.2 起源/释放-3.2

上面的步骤是不必要的重复。将来如果你

想要工作到释放分支-

sh$ git 签出版本-3.2 sh$ git 分支 bug-XYZ-释放-3.2 & & git 签出 bug-XYZ-释放-3.2 ...< 樱桃挑、砍、犯 >

建设

# # 环境设置

- 为有关构建环境所需要的软件包的详细信息请参阅: 建设 GlusterFS * *

Ubuntu:

要设置在 Ubuntu 系统的构建环境，请键入以下命令命令以安装所需的软件包︰

sudo apt-get 来 y 安装 python pyxattr libreadline-dev systemtap-特殊和差别待遇-dev 焦油 python pastedeploy python simplejson python 狮身人面像 python webob libssl-dev pkg 配置 python 开发 python eventlet python netifaces libaio-dev libibverbs-dev libtool libxml2-dev liblvm2-dev 使 autoconf automake 野牛 dos2unix flex libfuse-dev

CentOS/RHEL/Fedora:

在 Fedora 系统上，通过以下安装所需的软件包指示在 CompilingRPMS。

# # 创建生成环境

一旦您适当的系统安装了所需的软件包生成的生成配置︰

sh$./autogen.sh sh$./ 配置 — — 启用 fusermount

# # 构建和安装

# # GlusterFS

Ubuntu:

键入以下命令生成并在系统上安装 GlusterFS:

sh$ 使 sh$ 使安装

CentOS/RHEL/Fedora:

在基于 rpm 的系统中，有两种方法来生成 GlusterFS。其中一个是

使用该方法描述以上为 * Ubuntu *。另一种是打造和

安装 RPM，如述 CompilingRPMS。

# # GlusterFS UFO/斯威夫特

生成并运行 Gluster 不明飞行物可以执行以下操作︰

1.建立、创建和安装 RPM，如中所述 [] CompilingRPMS(./Compiling-RPMS.md)。

2.配置 UFO/斯威夫特 [如何使用不明飞行物斯威夫特-快速所述和脏安装程序指南] (http://www.gluster.org/2012/09/howto-using-ufo-swift-a-quick-and-dirty-setup-guide)

实施策略

Gerrit 基于工作流，每个提交都应该是一个独立的、可建房和可测试性的变化。通常你会有一个本地的分支

每个任务和大多数时候那根树枝会提交一次。

如果你有第二个任务手头这取决于的变化第一个，然后从技术上讲你可以把它当顶上的单独提交第一次提交。但它是重要的应该是第一次提交

可测试更改本身 (如果不是，是的征兆，这两个提交是本质上的单个更改的一部分）。Gerrit 容纳

这些情况将改变 1 标记为"依赖"的变化 2 （还有一个依赖项选项卡中更改页面在 Gerrit）自动当您将更改推送审查从相同的地方分支。

您将需要注销您的提交 (git commit-s) 在发送之前审查的修补程序。通过签署掉你的补丁，您同意条款

列出在"开发人员的产地来源证"节中特约文件存储库根中可用。

提供有意义的提交消息。您的提交消息应该在

以下格式

-描述该修补程序的完成短一线主题 -以下主题空线 -需要该修补程序的情况 -的代码更改的说明 -（比别人）这样做的理由 -测试用例的描述

# # 测试用例

工作流的一部分是对聚合和执行前提交测试用例哪个陪累积为每个新修补程序的修补程序。这

保证测试，到目前为止，工作不是坏了使用最新的补丁。每次更改提交给 Gerrit 多包括测试

在例

tests/group/script.t

作为该修补程序的一部分。这是因而代码更改和伴随测试

案件审理一起。所有新提交现在来下

以下类别 w.r.t 测试用例︰

对于任何新的功能，放在网上供审查，应伴随着一组测试中 [] distaf(https://github.com/gluster/distaf/blob/master/README.md)。这些

将运行测试，每晚和（或）前释放来确定健康功能。请阅读

如何为

有关如何编写和执行测试在 distaf 的详细信息。

# # 新 '小组' 目录和/或 'script.t'

这通常是当代码将添加一个新的模块和/或功能

# # 扩展/修改旧测试用例中的现有脚本

这通常是当存在行为（默认值等）的代码是更改

# # 没有测试用例

这通常是当代码更改很简单（如固定中的拼写错误输出字符串，代码注释）

# # 只有测试用例和无代码更改

这通常是当我们将测试用例添加到旧代码（已经前此回归测试策略存在是强制执行）

有关如何与测试用例的脚本的更多详细信息可以在发现

测试/自述文件

审查过程

# # rfc.sh

之后，做本地提交，它是提交的代码审查的时间。有可用的脚本内称为 rfc.sh 的 glusterfs.git。您可以

通过简单地执行提交审查所做的更改

sh$。 /rfc.sh

此脚本将执行以下操作︰

-第一次执行，它可以下载从 git 钩 < http://review.gluster.org/tools/hooks/commit-msg >，并设置本地以生成更改 Id︰您的提交消息中的标记 (如果它不是已经生成。） -重订你提交针对最新的上游压头。这等闲

也会导致你提交接受按摩从刚下载的提交味精钩。 -提示输入每次提交 Bug Id （如果它已经不是 provded）并将它作为"BUG:"在提交日志中的标记。你可以只击中

在此提示符下，如果您的提交是纯粹是为了审查目的。 -将更改推送到 review.gluster.org 进行审查。如果你有

提供一个 bug id，它将作为"bug XYZ"分配变化的主题。如果不是它设置为"rfc"主题。

在一个成功的推，你会看到一个 URL 指向的变化 review.gluster.org

自动验证

詹金斯和 Gerrit 之间的集成将触发一个事件在詹金斯对每一个变化，努力拿起变化和运行的生成以及烟对它进行测试。

如果生成和冒烟测试成功执行，标志着詹金斯更改为 ' + 0 验证 '。如果他们失败了，'-1 验证' 标记上

更改。这意味着通过自动化的烟雾测试是必要的

但不是充分条件。

很重要的是要注意，詹金斯核查是只有泛型高水平的测试验证。更多的集中测试工作量

此修补程序是必要的与手动验证。

如果自动验证失败，这是一个好的原因要跳到的代码审查固定的变化被推后。你可以点击生成 URL

自动把作为检查汽车的原因的注释验证失败。在詹金斯工作页面中，您可以点击

控制台输出链接看到确切的故障点。

审查/评论

相比其他可用 Gerrit 代码审查是相对比较容易工具。每次更改提出了多个文件和每个文件可以

在肩并肩模式进行审查。在检讨时是有可能的评论

通过双击它写在您的评论在每一行上文本框。这种在行注释保存为草稿，直到你

最后将它们发布作为审查从 '更改页'。

有许多小和方便功能在 Gerrit，像主演你有兴趣跟随，设置的背景中，以量的变化查看在并排的视图页面等。

纳入，rfc.sh，重新修改

代码审查意见通过电子邮件通知。后将纳入

在代码中的更改，您可以标记每个内联注释作为 '做' （可选）。后到您的本地文件的所有更改，修改

与这种变化-上一次提交

sh$ git commit-a — 修订

通过执行 rfc.sh 推动修订的提交。如果你上一次推送

"rfc"推（即，没有 Bug Id）将提示您输入一个错误 Id 再一次。你可以重新推到太 rfc 变化没有任何其他的代码更改

通过给一个 Bug id。

在推新人、詹金斯将重新验证（独立的新变化核查结果是什么以前推）。

它是在提交日志（这不会更改）中的更改 Id 线，将新推关联作为对于老推送更新 (即使他们有不同的提交 id）下相同的更改。在肩并肩

查看页面，就可以在修补程序历史记录选项卡中设置旋钮查看修补程序以及之间的更改。这是非常方便的检查如何

纳入了审查意见。

如果进一步变化发现必要，可以在新作出评论修补程序，以及和相同的周期重复。

如果没有进一步的更改是必要的审阅者可以将标记作为修补程序综述了一定的成绩，取决于审查深度和（+ 1 或 + 2）的信心。-1 进行的审查表明非协议为

要获得上游合并变更。

回归测试和测试用例

所有的代码变更，是不平凡（错字修复，代码注释新的测试用例脚本必须附上更改）或扩展或修改现有的测试用例的脚本。它是重要的审查

结合分析的代码更改的测试用例是否代码更改实际验证了测试用例。

回归测试（即，执行的所有测试用例与积累测试用例可以不会自动触发每个提交）广泛和成本相当高，为每个更改提交执行在审查/重新提交周期。相反，它由触发

维护人员后代码审查。通过回归测试是

合并和代码的必备条件审查点。

提交预选赛

以更改合并进来，有两场预选赛，这强制执行通过 Gerrit 系统。他们是 — — 变化应至少有一个 ' + 2

综述了 '，变化应该有至少一个 '+ 1 验证' （回归测试）。项目的维护者将一次合并更改

修补程序符合这些限定符。

提交那些不合资格

有三种类型的"反对票"。

-1 验证

-1 的代码审查（"我宁愿你没有提交这"）

-2 的代码审查（"不要提交"）

含义和范围的所有的三个都是不同的。他们

当更改重新作为新补丁集的行为不同。

# #-1 验证

任何人投票-1 验证将防止 *that 补丁 only\ * 从获取合并。在下一个补丁集自动清除该标记

发布。意图是这次投票基于的一些结果

类型的测试。选民预计将解释该测试用例的

失败。詹金斯的作业（烟，回归，ufounit）使用此字段

投票-1/0 / + 1。投票时为-1，詹金斯帖子链接到的 URL，

已失败的作业的控制台输出。

# #-1 代码审查（"我宁愿你没有提交这"）

这是基于该修补程序的内容咨询投票。通常

问题在源代码中（设计和执行情况）源代码评论，日志消息，许可证等人类检测发现标题。审阅者通过评论危害最大，说明具体问题此修补程序的源代码的相关行。在重新提交，-1 票

自动清除。它是维护人员的责任

为了纪念-1 代码评审投票从审阅者 (通过不合并修补程序），检查-1 对以前提交的评论，在新的补丁解决。通常这是推荐的

"反对票"。

# #-2 代码审查（"不要提交"）

这是一个更强的投票实际上阻止 Gerrit 合并修补程序。-2 票甚至后重新提交仍然存在，并继续

防止此修补程序得到合并，直到选民撤销-2 投票（，然后进一步遭受提交限定符）。通常

如果他们是 *against，一个将投票-2 goal\ * 的修补程序是想要实现（而不是问题与该修补程序，可以更改重新提交）。审阅者即使有也会投票-2 对修补程序

与目标，但代码中的问题的协议是关键审阅者个人想要检查下一个补丁集的性质和才撤销表决后找到新的修补程序令人满意。这可以防止合并的平均时间中的修补程序。每个注册

用户有权行使-2 代码审查投票，并不能由维护人员重写。