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

原创
2017/03/15 19:44
阅读数 27W

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 中文解释 Group Slack Channel Meetings
API Machinery API机制 Group #sig-api-machinery Every other Wednesday at 11:00 AM PST
Apps 应用 Group #sig-apps Mondays 9:00AM PST
Auth 权限和认证 Group #sig-auth Biweekly Wednesdays at 1100 to 1200 PT
Autoscaling 自动扩缩容 Group #sig-autoscaling Biweekly (or triweekly) on Thurs at 0830 PT
AWS aws公有云 Group #sig-aws We meet on Zoom, and the calls are scheduled via the official group mailing list
Big Data 大数据 Group #sig-big-data Wednesdays at 10am PST, link posted in the official group.
CLI 命令行 Group #sig-cli Bi-weekly Wednesdays at 9:00 AM PT on Zoom
Cluster Lifecycle 集群生命周期 Group #sig-cluster-lifecycle Tuesdays at 09:00 AM PST on Zoom
Cluster Ops 集群操作 Group #sig-cluster-ops Thursdays at 1:00 PM PST on hangouts
Contributor Experience 贡献者体验 Group #wg-contribex Biweekly Wednesdays 9:30 AM PST on zoom
Docs 文档 Group #sig-docs Tuesdays @ 10:30AM PST on Zoom
Federation 集群联邦 Group #sig-federation Bi-weekly on Monday at 9:00 AM PST on hangouts
Instrumentation 测量 Group #sig-instrumentation Thursdays at 9.30 AM PST
Network 网络 Group #sig-network Thursdays at 2:00 PM PST on Zoom
Node 节点 Group #sig-node Tuesdays at 10:00 PT
On Prem 私有云 Group #sig-onprem Every two weeks on Wednesday at 9 PM PST / 12 PM EST
OpenStack OpenStack Group #sig-openstack Every second Wednesday at 5 PM PDT / 2 PM EDT
PM 项目管理 Group #kubernetes-pm TBD
Rktnetes Group #sig-rktnetes As needed (ad-hoc)
Scalability 性能和可扩展性 Group #sig-scale Thursdays at 09:00 PT
Scheduling 调度 Group #sig-scheduling Alternate between Mondays at 1 PM PT and Wednesdays at 12:30 AM PT on Zoom
Service Catalog 服务目录 Group #sig-service-catalog Mondays at 1 PM PST
Storage 存储 Group #sig-storage Bi-weekly Thursdays 9 AM PST (or more frequently) on Zoom
Testing 测试 Group #sig-testing Tuesdays at 9:30 AM PT
UI UI Group #sig-ui Wednesdays at 4:00 PM CEST
Windows Windows Group #sig-windows Bi-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和内存的限制。这反过来增加了社区的繁荣和项目的演进,这样,大型项目的开发就变成了一个大型的在线游戏,玩的开心的人提供了源源不断的提供创造力。

展开阅读全文
打赏
0
1 收藏
分享
加载中
更多评论
打赏
0 评论
1 收藏
0
分享
返回顶部
顶部