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

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(在线聊天，但我上去发现人不大多)，定期开会

• 这些组可以大致分为这么几类

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

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

  • 周边依赖： aws，openstack，网络，存储

  • 应用：大数据，应用，私有云

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

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

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

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

• PR审核和合入的平均时长

• issue解决的平均时长

• 社区的代码提交率

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和内存的限制。这反过来增加了社区的繁荣和项目的演进，这样，大型项目的开发就变成了一个大型的在线游戏，玩的开心的人提供了源源不断的提供创造力。