SIG Architecture 特别报道：代码组织

2024.04.11

作者: Frederico Muñoz (SAS Institute)

译者: Xin Li (DaoCloud)

这是 SIG Architecture Spotlight 系列的第三次采访，该系列将涵盖不同的子项目。我们将介绍 SIG Architecture：代码组织。

在本次 SIG Architecture 聚焦中，我与代码组织子项目的成员 Madhav Jivrajani（VMware）进行了交谈。

介绍代码组织子项目

Frederico (FSM)：你好，Madhav，感谢你百忙之中接受我们的采访。你能否首先向我们介绍一下你自己、你的角色以及你是如何参与 Kubernetes 的？

Madhav Jivrajani (MJ)：你好！我叫 Madhav Jivrajani，担任 SIG 贡献者体验的技术主管和 Kubernetes 项目的 GitHub 管理员。除此之外，我还为 SIG API Machinery 和 SIG Etcd 做出贡献，但最近，我一直在帮助完成 Kubernetes 保留受支持的 Go 版本所需的工作，正是通过这一点，参与到了 SIG Architecture 的代码组织子项目中。

FSM：像 Kubernetes 这样规模的项目在代码组织方面肯定会遇到独特的挑战 -- 这是一个合理的假设吗？如果是这样，你认为 Kubernetes 特有的一些主要挑战是什么？

MJ：这是一个合理的假设！第一个有趣的挑战来自 Kubernetes 代码库的庞大规模。我们有大约 220 万行 Go 代码（由于 dims 和这个子项目中的其他人的努力，该代码正在稳步减少！），而且我们的依赖项（无论是直接还是间接）超过 240 个，这就是为什么拥有一个致力于帮助进行依赖项管理的子项目至关重要：我们需要知道我们正在引入哪些依赖项，这些依赖项处于什么版本，以及帮助确保我们能够以一致的方式管理代码库不同部分的依赖关系的工具。以一致的方式管理代码库不同部分的这些依赖关系。

Kubernetes 的另一个有趣的挑战是，我们在 Kubernetes 发布周期中发布了许多 Go 模块，其中一个例子是 client-go。然而，作为一个项目，我们也希望将所有内容都放在一个仓库中，便获得使用单一仓库的优势，例如原子性的提交…… 因此，代码组织与其他 SIG（例如 SIG Release）合作，以实现将代码从单一仓库发布到下游仓库的自动化过程，下游仓库更容易使用，因为你就不必导入整个 Kubernetes 代码库！

代码组织和 Kubernetes

FSM：对于刚刚开始为 Kubernetes 代码做出贡献的人来说，在代码组织方面他们应该考虑的主要事项是什么？你认为有哪些关键概念？

MJ：我认为至少在开始时要记住的关键事情之一是 staging 目录的概念。在 kubernetes/kubernetes 中，你会遇到一个名为 staging/ 的目录。该目录中的子文件夹充当一堆伪仓库。例如，发布 client-go 版本的 kubernetes/client-go 仓库实际上是一个 staging 仓库。

FSM：那么 staging 目录的概念会从根本上影响贡献？

MJ：准确地说，因为如果你想为任何 staging 仓库做出贡献，你需要将 PR 发送到 kubernetes/kubernetes 中相应的 staging 目录。一旦代码合并到那里，我们就会让一个名为 publishing-bot 的机器人将合并的提交同步到必要的 staging 仓库（例如 kubernetes/client-go）中。通过这种方式，我们可以获得单一仓库的好处，但我们也可以以模块化的形式发布代码以供下游使用。 PS：publishing-bot 需要更多人的帮助！

FSM：说到贡献，贡献者数量非常多，包括个人和公司，也一定是一个挑战：这个子项目是如何运作的以确保大家都遵循标准呢？

MJ：当涉及到项目中的依赖关系管理时，有一个专门团队帮助审查和批准依赖关系更改。这些人为目前 Kubernetes 用于管理依赖的许多工具做了开拓性的工作。这些工具帮助我们确保贡献者可以以一致的方式更改依赖项。这个子项目还开发了其他工具来基于被添加或删除的依赖项的统计信息发出通知： depstat

除了依赖管理之外，这个项目执行的另一项重要任务是管理 staging 仓库。用于实现此目的的工具（publishing-bot）对贡献者完全透明，有助于确保就提交给 kubernetes/kubernetes 的贡献而言，各个 staging 仓库获得的视图是一致的。

代码组织还致力于确保 Kubernetes 一直在使用受支持的 Go 版本。链接所指向的 KEP 中包含更详细的背景信息，用来说明为什么我们需要这样做。我们与 SIG Release 合作，确保我们在 Go 版本上尽可能严格、尽早地测试 Kubernetes；作为这些工作的一部分，我们要处理会破坏我们的 CI 的那些变更。我们如何跟踪此过程的示例可以在此处找到。

发布周期和当前优先级

FSM：在发布周期中有什么变化吗？

MJ：在发布周期内，特别是在代码冻结之前，通常会发生添加、更新、删除依赖项的变更，以及修复需要修复的代码等更改，这些都是我们继续使用受支持的 Go 版本的努力的一部分。

此外，其中一些更改也可以向后移植到我们支持的发布分支。

FSM：就子项目中目前正在进行的主要项目或主题而言你有什么要特别强调的吗？

MJ：我认为最近添加的一个非常有趣且非常有用的变更（我借这个机会特别强调 Tim Hockin 在这方面的工作）是引入 Go 工作空间的概念到Kubernetes 仓库中。我们当前的许多依赖管理和代码发布工具，以及在 Kubernetes 仓库中编辑代码的体验，都可以通过此更改得到显着改善。

收尾

FSM：对这个主题感兴趣的人要怎样开始帮助这个子项目？

MJ：与 Kubernetes 中任何项目的第一步一样，第一步是加入我们的 Slack：slack.k8s.io，然后加入 #k8s-code-organization 频道，你还可以选择参加代码组织办公时间。时区是个困难点，所以请随时查看录音或会议记录并跟进 Slack！

FSM：非常好，谢谢！最后你还有什么想分享的吗？

MJ：代码组织子项目总是需要帮助！特别是像发布机器人这样的领域，所以请不要犹豫，参与到 #k8s-code-organization Slack 频道中。