如何帮助OpenStack开发者成为贡献者

CI(Continuous Integration)意为 “持续整合”,指代码的持续测试及与其他代码修改的整合与归并。CD(Continuous Deployment)意为 “持续部署”,指代码与其补丁的持续部署于整个代码库。拿文档来看,就是内容的持续测试、与必要修改的归并及部署。在此,部署意为发布。举例来说,“部署文档”是指输出文件被复制于web服务器为人阅览。

文档的持续整合与持续部署

任何OpenStack库,包括文档库的修改只能通过Gerrit 代码查核系统完成。Gerrit是由OpenStack基础架构团队运营管理的基于网页的附加查核工具,用于代码协作及审阅。其工作流程为:文档贡献者在文档库中核对文档,做出修改,在本地测试,提交至git – 资源管理及修订系统,后上传至OpenStack的Gerrit事例。Gerrit将修改通知到为软件开发提供持续整合服务的Jenkins。Jenkins收到通知后,将运行为该库配置好的测试包。目前,OpenStack有八个并行的Jenkins事例,由自主开发的工具Zuul协调 (http://status.openstack.org/zuul/)。

任何人都可以在OpenStack的Gerrit成为审阅者

  • 0: 无分数。
  • +1: 我觉得可以通过,但需要他人同意。
  • 1: 该修改还需完善,以成为可归并的补丁。

补丁本身同样需要评议来阐述其必需性、寻求附加说明,或对补丁作出肯定。

资历较深的“核心审阅者”可为修改做出“+2”或“-2”的评分,以决定修改可否成为修补并发布:

  • +2: 同意(核心审核人)
  • 2: 不同意

被两位核心审阅者评以“+2”的修改将通过审核,被归并、发布。得负分的修改不会被批准,相关文档在达到共识之前也不会被发布。

Jenkins的自动测试也可在审阅过程中形成评分。

当修改被批准后,Jenkins将对已与该修改归并,更新后的git 库进行测试,确保避免出现复归。修改只有被Jenkins审核通过后才可以被归并。

以上所有自动更改都可运行于HP和Rackspace公有云。目前,OpenStack项目为此目的运行的虚拟机已达到950台,每项测试工作对应一台机器,检验被测试的修改所在的库,安装测试包所需组件并运行测试包 是的,OpenStack正在用云来管理自身云的相关文档。

下面的章节中将列出OpenStack目前正在运行的测试。

持续集成与持续部署借鉴于文档的优势何在?

每天都有多个OpenStack项目与多个修改归并,而文档系统与之同步的能力是必要的。持续集成与持续部署让其得以实现 – 这在当下的环境中是必需的,而非仅是优势。作者与开发者的工作流程相同,会得到相同的认可、奖励。

这套流程让创建文档不再是本地作者的负担,尽管贡献者仍需在本地建立文档。可修改、审阅就绪的拟定文档让贡献者避免了下载补丁、复制创建环境、再建立文档的繁复流程,实现同时阅览原始文件和输出文件。

创建文档的速度也会提高,因为作者可在CI/CD运行的同时完善多个修补。OpenStack的基础架构团队已将类似技术用于服务器管理。

由于测试脚本的限定,作者会一直以工作状态为起始,逐渐完善所建文档的各个分支。如文档不能在本地或者其他环境创建,作者可以确定是自身问题,而非文档分支的中断。

拟定文档的创建和发布将使审阅者能够快速了解一项修改的实施效果,而无需下载并在本地建立,从而更快速的完成审阅。

这与OpenStack开发者与基础架构团队使用的工作流程相同,开发者们可以更轻松的成为文档贡献者。而近期向RST格式的转变更是将这个优势强化:RST是OpenStack的常用审定语言。

自动化的风险与陷阱

鉴于文档撰写本身的特性,OpenStack一直在尝试平衡自主创建与人为修饰。一些早期疑虑包括过急的发布与不完整文档的发布。我们发现,只要审阅者能够以一项修改可否解决自己在实践中遇到的问题作为该修改可否通过的评定标准,那么更新发布过于频繁的风险就会降低。

尽管审阅者之间相互信任,大家依旧会在每半年举行一次的峰会上相聚,就需审阅的文档展开讨论。一些详尽的审阅指南已发布(详见https://wiki.openstack.org/wiki/Documentation/ReviewGuidelines);有关如何高效判断修补质量的培训也在持续进行。以机器测试结果为支撑,来自可靠的审阅者的正确判断与持续整合同为发布速度的决定因素。

所述指南由两部分组成:独立于版本的内容以及关于最新版本的内容。基于某一版本制订的指南,例如安装说明,会跟随每个新版本而更新。已发布的文档会根据关键修改而更新,为下一版本准备的文档将被大幅修改并隐藏于现有拟定版文档,以便当前拟定版本的审阅。在新的软件版本发行后,与之对应的指南将被发布。之后,下一个版本的指南更新工作将展开。

文档测试

Jenkins 可执行脚本,文档团队也拥有自己的测试脚本库 (https://github.com/openstack /openstack­doctools),大部分使用Python撰写。开发这些脚本的流程与文档创建的工作流程是相同的。主要修改完成后,测试工具的一个发行版本之完成,并用于对文档修改的测试。文档库使用test­requirments.txt 文件的Python惯例示意 openstack­doc­tools的哪个版本对应哪套文档源文件。

自动测试将细究文档的形态,使审阅者能够专注于内容。尽管文档无需通过全部自动测试,它必须通过被定义为“评分”的测试内容才可以被归并及发布。另一部分测试内容被定义为“非评分”,指不是必须通过的测试内容。

一些自动测试的内容包括:

· 检查独立文件的语法,帮助查找语法错误,可用于DocBook XML, WADL XML, RST, 以及 JSON格式。在此我们只对DocBook XML 和 RST执行此测试。对于JSON的格式检查另有其他测试完成。

· 检查文档的创建。它的附加价值在于新生成的指南将被上传至拟定文档服务器,方便审阅者在HTML和PDF格式中查阅。

· 检查指南译本通过工具链创建。

· 检查文件精致度:根据不同的文件格式(XML, RST, 或JSON)检查文档格式、留白是否恰当、字符是否统一、影响查阅源文件的诸多细节等。我们的工具链无法输出一些统码,且JSON文件需符合格式标准。

· 检查网页链接是否可用,确保DocBook XML格式文件里的URL全部有效。鉴于一些网站本身可能失效,这项为“非评分”测试。

· 检查用于其他指南的XML 文件没有被删除。这项的重要性在于我们只创建修改的指南,因此需确保单一文件的删除不会影响文档的创建。

OpenStack也对测试脚本中完成了优化。例如,鉴于创建DocBook XML文件是贵重的,小型的关联创建工具可查看哪些文件被修改、被哪些指南涵盖,从而只创建相关指南。其他测试,例如语法或URL测试同样也只在有修改的文件执行,而无需检查没有修改的文件 –相比测试单个文件,对近千个 XML文件进行检查会略显迟缓。

这些优化未在RST文件完成,鉴于RST文件更易于解析,据此创建文档也更快速。

鉴于评分机制所需的准确性,我们不会对文字语法或拼写创建测试。关于这个话题的讨论有过很多,但的确,这是一项需要人为判断的工作。

持续整合架构的其他用途

持续整合架构曾出现在翻译服务器的讨论中。目前,转译服务器“Transifex”被用于指南的翻译工作。当有修改被归并时,持续整合架构将当前文字上传至转译服务器,方便译员直接将文字转译并一直拥有最新的字列。每天一次,一个所谓的“周期性”工作被运行于持续整合架构,下载全部完成转译的字列至文档库。之后,对于其他字列的修改被提出。这一机制让我们得以将导入的转译与指南审阅一起通过持续整合架构运行。

此外,持续整合架构也被用于分享文件在库之间的同步。这些是共享的专业术语列表以及同用于其他转译的附录。修改被归并于这些文件的主库后,系统将检查其他库中的文件是否也需更新。如有需要,对其他库的修改将被直接通过。这样,测试包被运行于转译内容,同时再次确认指南的内容无误。

总结

本文旨在帮助读者了解我们如何将OpenStack文档编制与持续整合以及持续部署技术相结合。我们发现,这样结合的利远大于弊。我们需要与其他团队相符,进而需要尽早、尽量频繁的发布。用自动化的视角看看你的开源文档,巧妙之处自会显现。

原文由Anne 与Andreas Jaeger共同撰写。Anne 与 Andreas同为OpenStack文档团队成员。Andreas 曾就职于SUSE,对OpenStack持续整合架构有深入研究,为不同的开源项目贡献超过20年。

本文作者:佚名

来源:51CTO

时间: 2024-12-17 19:49:06

如何帮助OpenStack开发者成为贡献者的相关文章

OpenStack七年盘点,热潮褪去后的明天在哪?

OpenStack 于 2010 年发布,到现在已有 7 年之久.几年前云计算的星星之火,现在业已成燎原之势.这几年,有 CloudStack 卖身.Nebula 倒闭.Docker 出世等等大事,OpenStack 的七年之痒,未来将何去何从? 写在前面 2006 年,亚马逊正式推出其第一个云计算服务,没过几年,云计算的烈火燎原之势便开始在全球铺展开来.4 年之后,开源软件 OpenStack 诞生,并呈现了野蛮式的增长,社区以及企业希望通过 OpenStack 的方式来帮助他们打造属于自己的

红帽谈基于OpenStack和Kubernetes的容器管理的未来

本文讲的是红帽谈基于OpenStack和Kubernetes的容器管理的未来,[编者的话]OpenStack是搭建私有云平台的事实标准:而Kubernetes作为谷歌集群管理系统Borg的开源版本,在容器集群管理方面前景光明.本文重点介绍了红帽在深度整合OpenStack和Kubernetes的尝试. 这个星期,在波特兰召开的OSCON 2015会议上,我们同谷歌以及其他成员一起庆祝了Kubernetes 1.0的发布以及CNCF(Cloud Native Computing Foundatio

OpenStack社区正式接受UnitedStack有云Steth项目

由UnitedStack网络组提出并创建的Steth项目,在上周日(1月17日)正式并入Big Tent,成为OpenStack正式项目.该项目主要针对网络故障排查和部署前的硬件网络环境检查. 这是自Big Tent模式确认以来,UnitedStack有云第一个并入Big Tent的项目,也是继Scalpels项目和pandaman之后,来自中国的项目再次被社区接纳.作为OpenStack开源社区的一员,我们既是受益者,也是社区的建设者和所有人. Steth项目因何而来?解救忙碌的网络工程师 S

对抗OpenStack:Riak与CloudStack结盟

9月5日,知名开源NoSQL数据库Riak背后的Basho宣布与http://www.aliyun.com/zixun/aggregation/13752.html">开源云平台Apache CloudStack合作,将其存储服务RiakCS与后者平台整合. Basho CTO Justin Sheehy CloudStack希望成为AWS的备选平台,因为两者兼容.但CloudStack正受到来自Eucalyptus和OpenStack双重压力.与OpenStack不同,CloudStac

有关OpenStack的“但丁密码”

在这里要讲述的OpenStack"但丁密码"和电影中的失忆.追杀.穿越欧洲的时间赛跑以及阴谋没有什么关系,这里要讨论OpenStack开源应用的问题.尽管看起来平淡了很多,但精彩的内容一点不少. 云计算的选择 毫无疑问,云计算是当今用户最为关注的应用.据相关数据预测,到2018年,我国私有云市场规模将接近千亿元水平,至2020年市场规模有望达到5500亿元,前景非常诱人.但用户所真正关注的其实是业务敏捷性.资源弹性和灵活部署,这也是云计算倍受追捧的原因. 让云计算落地,用户有两种选择:

基于OpenStack和Kubernetes的容器管理未来

[原文编者的话] OpenStack是搭建私有云平台的事实标准;而Kubernetes作为谷歌集群管理系统Borg的开源版本,在容器集群管理方面前景光明.本文重点介绍了红帽在深度整合OpenStack和Kubernetes的尝试. 这个星期,在波特兰召开的OSCON 2015会议上,我们同谷歌以及其他成员一起庆祝了Kubernetes 1.0的发布以及CNCF(Cloud Native Computing Foundation)基金会的建立.其中,红帽.谷歌和其他一些公司都是CNCF基金会的创始

OpenStack将怎样影响软件行业?

云盈四海中国加速器 (Stratus Alliance) 创始人檀林在微博上分享了看花旗银行的 报告,以下是报告摘译. 报告亮点 图:E版和G版代码贡献量对比 OpenStack有太多贡献者,太多力量交织在一起,将延迟企业级部署:这并不是稳固的模式. 缺乏企业级供应商,在某些组件上还缺乏 稳定性.我们认为企业用户会先 寻找混合云的解决方案. 当OpenStack提供一些公有云服务时,AWS很可能变的更加成熟和获得更大的规模. 有观点认为,VMware在OpenStack生态环境的创新,让vClo

OpenStack成就云计算的一个美好未来

八月初八,初秋,黄昏 场景一:云计算的战场上 经过第一轮的拼杀,有的人已经闭上了眼睛,似乎这个战局的输赢已经注定--让IaaS领域的霸主亚马逊没有想到的是,正当得益于自己短暂的胜利而恍惚的时间里,一个素未蒙面的对手泰然地站在自己的对面,他的名字叫OpenStack. 亚马逊不敢相信自己的眼睛,好像被一股巨大的力量按住了脖子,视线变得有些模糊,等他好不容易缓过神仔细看清楚的时候,他发现,对手又仿佛不只是一个人.亚马逊顿时有一种不祥的预感,征战多年,遭遇过无数个有名头的强劲对手,如今会败在他根本没听

使用OpenStack构建Packet平台过程中的经验和教训

本文讲的是使用OpenStack构建Packet平台过程中的经验和教训,[编者的话]Packet是一家成立不久的公司,他们主要是为用户提供基于裸机服务器的IaaS,本文的作者是Packet平台的VP,作者在文中讲述了他们构建Packet平台的动机以及在构建过程中遇到了哪些问题.他们通过借鉴OpenStack已有的服务,如Neutron.Ironic,将OpenStack对于虚拟机集群的管理策略迁移到对物理机集群的管理上,同时作者还分享了在整个平台构建过程中的经验教训. 在去年夏天, Zac 找到