kubernetes社区组织和软件工程过程学习

举报
难易 发表于 2017/12/08 14:25:32 2017/12/08
【摘要】 不同软件开发社区的运行模式不大相同,但总体目标是一致的,就是广泛的聚集全球不同组织和身份的开发者进行某项软件的开发,海纳百川、兼容并包,那么在社区化开发的过程中,就会碰到如下的挑战

未标题-1.jpg

0. 社区化运作和kubernetes

不同软件开发社区的运行模式不大相同,但总体目标是一致的,就是广泛的聚集全球不同组织和身份的开发者进行某项软件的开发,海纳百川、兼容并包,那么在社区化开发的过程中,就会碰到如下的挑战

  • 不同组织和个人对社区的的诉求不同,粗略划分可以按照 开发者/用户,一般特性开发者/模块组织者等维度来划分,如何保持版本节奏有序,按时发布?

  • 设计质量和代码质量层差不齐,如何保证项目质量可控?

kubernetes社区是目前开源社区中运作比较规范,开发效率较高的一个社区,同时,也继承了google强大的软件工程实践,非常值得学习。

最近,kubernetes社区的交流的库从主项目交付件中脱离, 放在这里,从中可以探究社区项目的运作模式,并提升组织的开发效率。

1. 交流方式

  • 社区(Community)的本质是要进行交流(Communicate)

  • 主要交流方式为使用github进行交流,使用issue/milestone/PR等方式交流,这种方式

    • 所有交流过程都是开发团队全员可见的,避免了使用聊天工具、邮件等把信息束缚在几个人可见的形态下

    • 任何独立的交流方式,最后都要存档为其他人可见,例如google doc,或者文档

  • 次要交流方式包括了论坛,slack,在线会议,这些交流方式的频次不算高,但可以有一些专注的深度交流

    • 由于开源团队分布在全球各个时区,举办meeting的成本非常高,所以大家在开会前基本都会做充足的准备,把分歧点和决断点都搞的比较明确,所以会议的效率反而很高

    • 不少大公司由于开会的成本很低,反而会议效率低下,无法在会上做快速决策和深度讨论

    • 开会主要是做决策,不去解决具体问题

  • 改进方法

    • 组内设计、讨论,bug处理,尽量不使用邮件或即时聊天工具,用提PR/issue的方式来做

    • 会议分为两种,一种是少数人为了讲清楚情况,在白板前自发召集人讨论,这种会议是高效的。另一种专门到会议室开会,需要在会议系统内做跟踪,把会议时长 *人数作为指标,并反馈给大家。必要时可以在会议系统中设置“会议配额”,限制团队开会的时长。

2. 组织方式: SIGs(Special Interest Group)

  • 把社区中的人分为20多个组,从组的划分可以看出社区的关注点,每个组的Leader有大的决策权,类似于美国政治中的联邦制

  • 每个组有独立的论坛(Google Group),和Slack(在线聊天,但我上去发现人不大多),定期开会

Name中文解释GroupSlack ChannelMeetings
API MachineryAPI机制Group#sig-api-machineryEvery other Wednesday at 11:00 AM PST
Apps应用Group#sig-appsMondays 9:00AM PST
Auth权限和认证Group#sig-authBiweekly Wednesdays at 1100 to 1200 PT
Autoscaling自动扩缩容Group#sig-autoscalingBiweekly (or triweekly) on Thurs at 0830 PT
AWSaws公有云Group#sig-awsWe meet on Zoom, and the calls are scheduled via the official group mailing list
Big Data大数据Group#sig-big-dataWednesdays at 10am PST, link posted in the official group.
CLI命令行Group#sig-cliBi-weekly Wednesdays at 9:00 AM PT on Zoom
Cluster Lifecycle集群生命周期Group#sig-cluster-lifecycleTuesdays at 09:00 AM PST on Zoom
Cluster Ops集群操作Group#sig-cluster-opsThursdays at 1:00 PM PST on hangouts
Contributor Experience贡献者体验Group#wg-contribexBiweekly Wednesdays 9:30 AM PST on zoom
Docs文档Group#sig-docsTuesdays @ 10:30AM PST on Zoom
Federation集群联邦Group#sig-federationBi-weekly on Monday at 9:00 AM PST on hangouts
Instrumentation测量Group#sig-instrumentationThursdays at 9.30 AM PST
Network网络Group#sig-networkThursdays at 2:00 PM PST on Zoom
Node节点Group#sig-nodeTuesdays at 10:00 PT
On Prem私有云Group#sig-onpremEvery two weeks on Wednesday at 9 PM PST / 12 PM EST
OpenStackOpenStackGroup#sig-openstackEvery second Wednesday at 5 PM PDT / 2 PM EDT
PM项目管理Group#kubernetes-pmTBD
Rktnetes
Group#sig-rktnetesAs needed (ad-hoc)
Scalability性能和可扩展性Group#sig-scaleThursdays at 09:00 PT
Scheduling调度Group#sig-schedulingAlternate between Mondays at 1 PM PT and Wednesdays at 12:30 AM PT on Zoom
Service Catalog服务目录Group#sig-service-catalogMondays at 1 PM PST
Storage存储Group#sig-storageBi-weekly Thursdays 9 AM PST (or more frequently) on Zoom
Testing测试Group#sig-testingTuesdays at 9:30 AM PT
UIUIGroup#sig-uiWednesdays at 4:00 PM CEST
WindowsWindowsGroup#sig-windowsBi-weekly Tuesdays at 9:30 AM PT
  • 这些组可以大致分为这么几类

    • 功能特性: API机制,自动扩缩容,命令行,集群生命周期,集群操作,节点,rkt,服务目录,UI

    • 性能和安全特性:权限和认证,监控测量,性能和可扩展性

    • 周边依赖: aws,openstack,网络,存储

    • 应用:大数据,应用,私有云

    • 项目支撑工作:文档,贡献者体验,项目管理,测试

  • 一般的功能特性都会被各个公司的活动覆盖,但在项目支撑工作的这几项上做的就很少,尤其是贡献者体验这一项,没有比较好的覆盖。开源社区为了吸引开发者贡献代码,会有专门的文档和流程指导新手开发者进入贡献的道路,但在大部分公司依赖于口头交流,会降低新入门开发者的成长速度,导致人月神话效应明显。

3. 开发效率的度量和提升

在工程学的任何领域,如果想要提升效率,首先需要找到合适的指标进行度量。如果一项改进措施有效,那么在这些指标中应该有正向反应,那么就可以保留;如果无效,那就放弃。目前可以作为效率度量的指标有:

4. 文档

  • 一般使用markdown格式,在github上可以直接查看,并专人持续维护。避免了传统软件开发中设计时写了一大堆word/PPT文档,但难以更新、搜索、查找的困境

  • 设计文档和代码同时提交,一般来说设计文档通过PR来提交,由Maintainer审核后就基本可以按此开发

5. 贡献者体验

  • 以任何一个PR为例子,Google搞了自己的CI机器人 ,在所有PR里面都能自动给PR分类、测试、打标签,还有Reviewable机器人,负责保证PR是可读的,任何开发者提交的PR都要先自行解决这两个问题,然后Reviewer才会去看这个代码怎么合入

  • 专门的开发者指导文档,涵盖了所有的开发者需要经历的流程、开发环境搭建、API和插件的编写方式

6. 项目管理

  • 搜集用户反馈,强化供应商中立性

  • 在kubernetes里面搞一个项目孵化器,当生态中有其他值得开展项目的时候做支撑

  • 寻找更多的公司贡献者

7. 测试

  • 从代码层级保证单元测试的代码和业务逻辑代码需要用一个PR提交,保证了整个项目的代码质量不会变差

  • 编写了端到端测试、整合测试、模拟器测试(性能)等多种方式

  • 大量使用CI和自动测试,所以我猜测他们测试的主要工作量也是编码

8. 结语

kubernetes社区是推进工程师文化非常好的一个例子。简单来说,社区的一切工作都是围绕着项目和开发者这两个维度来进行的,社区为开发者提供了一个比较好的持续学习和进步的机制,并在工作过程中把可以由机器自动化的部分直接用机器来完成,大幅提升效率。

开发者在社区所能体会到的自由,就像在操作系统下运行的进程一样,不必考虑CPU和内存的限制。这反过来增加了社区的繁荣和项目的演进,这样,大型项目的开发就变成了一个大型的在线游戏,玩的开心的人提供了源源不断的提供创造力。


【版权声明】本文为华为云社区用户原创内容,转载时必须标注文章的来源(华为云社区)、文章链接、文章作者等基本信息, 否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。