本文发表于一年多前。旧文章可能包含过时内容。请检查页面中的信息自发布以来是否已变得不正确。
聚焦 SIG Architecture：代码组织
这是 SIG Architecture Spotlight 系列的第三次访谈，将涵盖不同的子项目。我们将介绍 SIG Architecture: 代码组织。
在这次 SIG Architecture 聚焦中，我与代码组织子项目的成员 Madhav Jivrajani (VMware) 进行了交谈。
代码组织子项目简介
Frederico (FSM)：你好，Madhav，感谢你抽出时间。你能先简单介绍一下你自己、你的角色以及你是如何参与到 Kubernetes 中的吗？
Madhav Jivrajani (MJ)：你好！我叫 Madhav Jivrajani，我是 SIG Contributor Experience 的技术负责人，也是 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。然而，我们作为一个项目也希望享受到将所有东西都放在一个仓库中的好处，以获得使用单一仓库（monorepo）的优势，比如原子提交……所以，因此，代码组织与其他 SIG（如 SIG Release）合作，自动化将代码从单一仓库发布到下游各个仓库的过程，这些仓库更容易被消费，这样你就不必导入整个 Kubernetes 代码库了！
代码组织与 Kubernetes
FSM：对于刚开始为 Kubernetes 贡献代码的人来说，在代码组织方面，他们应该考虑的主要事项是什么？你会如何总结关键概念？
MJ：我认为，至少在你刚开始时，要记住的一个关键概念是 staging 目录。在 kubernetes/kubernetes 仓库中，你会遇到一个名为 staging/ 的目录。这个目录中的子文件夹充当了一系列伪仓库。例如，发布 client-go 版本的 kubernetes/client-go 仓库实际上是一个 staging 仓库。
FSM：所以 staging 目录的概念从根本上影响了贡献？
MJ：没错，因为如果你想为任何 staging 仓库做贡献，你需要向 kubernetes/kubernetes 中相应的 staging 目录提交一个 PR。一旦代码合并到那里，我们有一个名为 publishing-bot 的机器人，它会将合并的提交同步到所需的 staging 仓库（如 kubernetes/client-go）。这样我们既能获得单一仓库的好处，又能模块化地发布代码供下游消费。附注：publishing-bot 需要更多人来帮忙！
有关 staging 仓库的更多信息，请参阅贡献者文档。
FSM：说到贡献，大量的贡献者，包括个人和公司，肯定也是一个挑战：子项目如何运作以确保标准得到遵守？
MJ：当涉及到项目中的依赖管理时，有一个专门的团队来帮助审查和批准依赖项变更。这些人为 Kubernetes 今天用于依赖管理的许多工具奠定了基础。这些工具有助于确保贡献者能够以一致的方式对依赖项进行更改。该项目还开发了额外的工具来显示正在添加或删除的依赖项的统计信息：depstat。
除了依赖管理，该项目做的另一项关键任务是管理 staging 仓库。实现这一点的工具（publishing-bot）对贡献者是完全透明的，并有助于确保 staging 仓库获得提交到 kubernetes/kubernetes 的贡献的一致视图。
代码组织还致力于确保 Kubernetes 保持在受支持的 Go 版本上。链接的 KEP 提供了更多关于我们为什么需要这样做的背景信息。我们与 SIG Release 合作，以确保我们尽可能早、尽可能严格地在 Go 版本上测试 Kubernetes，并处理作为这项工作一部分破坏我们 CI 的变更。我们如何跟踪这个过程的一个例子可以在这里找到。
发布周期和当前优先级
FSM：在发布周期中有什么变化吗？
MJ：在发布周期中，特别是在代码冻结之前，通常会有一些变更，这些变更会添加/更新/删除依赖项，修复作为我们保持在受支持的 Go 版本上工作的一部分需要修复的代码。
此外，其中一些变更也是我们支持的发布分支的向后移植的候选者。
FSM：子项目目前是否有正在进行的主要项目或主题，你想要特别强调的？
MJ：我认为最近添加的一个非常有趣且非常有用的变更是（我借此机会特别强调 Tim Hockin 在这方面的工作）在 Kubernetes 仓库中引入 Go 工作区。我们目前用于依赖管理和代码发布的许多工具，以及在 Kubernetes 仓库中编辑代码的体验，都可以通过这一变更得到显著改善。
总结
FSM：对这个主题感兴趣的人如何开始帮助这个子项目？
MJ：第一步，就像在 Kubernetes 中的任何项目一样，是加入我们的 Slack：slack.k8s.io，然后加入 #k8s-code-organization 频道。还有一个代码组织办公时间，你可以选择参加。时区是个难题，所以你也可以随时查看录音或会议记录，并在 Slack 上跟进！
FSM：太好了，谢谢你！你还有什么最后的评论想分享吗？
MJ：代码组织子项目总是需要帮助！特别是在像 publishing bot 这样的领域，所以不要犹豫，在 #k8s-code-organization Slack 频道中参与进来。