Kubernetes 特性分支Feature Branch工作流2017 贡献者峰会上的 Git 协作模式辩论【免费下载链接】communityKubernetes Community Documentation项目地址: https://gitcode.com/GitHub_Trending/com/community导读本文基于 Kubernetes Community 仓库中保存的 2017 年 12 月贡献者峰会KubeCon/CloudNativeCon North America 前夕讨论纪要 should-k8s-use-feature-branches.md完整还原了由 Brian Grant 主持、Aaron Crickenbergerspiffxp记录的Kubernetes 是否应该使用特性分支专题讨论。这场讨论直指当时 Kubernetes 主仓库kubernetes/kubernetes发布流程的核心矛盾——特性不断涌入 master、发布前只能靠数周的 code freeze 来稳定、发布经理却无力说不。文中系统梳理了特性分支方案的动机、粒度选择一 KEP 一分支、rebase/merge 策略、CI 测试支撑、fork 与分支的取舍等议题并给出了真实的 workload API 特性分支实践教训。读者读完可以完整掌握这场影响 Kubernetes 后续工程实践的 Git 协作模式辩论全貌理解其与 KEP 流程、monolith 拆分、发布节奏管理的联动关系。会议背景为什么在 2017 年底讨论特性分支这场会议发生在 2017 年 12 月 5 日KubeCon/CloudNativeCon North America 前一天地点是奥斯汀会展中心Austin Convention Center。按照 ContribSummitInformation.md 的说明贡献者峰会采用松散的 un-conference非会议形式以主持人和讨论话题为主任何人可以在鱼缸式fishbowl开放讨论中发言。议题本身由社区在会前提出并投票产生本场Should Kubernetes move to Feature branches?正是其中之一。讨论的起点非常直接围绕当时的发布节奏展开发布周期痛苦每个版本要花数周时间把特性合入再花数周时间做稳定性修复we spend several weeks putting features in, we spend several weeks stabilizing。发布经理权力缺失管理发布流程的人没有能力对特性说这个不能进我们不想推迟发布于是只能被动接受处于 powerless无力的状态。规模问题叠加当天早些时候的拆分 monolith议题已经指出项目已经拥有超过 90 个仓库见 breaking-up-the-monolith.md发布体量越来越大、越来越复杂并非所有东西都适合搬出 monorepo。基于上述痛点讨论者提出的核心判断是摆脱发布救火演练release fire drills的唯一出路是把门禁提前——在特性进入 master 之前就设置一道更早的关卡an earlier gate。核心提案特性在分支上开发而非直接合入 master讨论中 Brian Grant 提出的方案是借鉴 gitflow 之类的模型让特性在独立的特性分支feature branch上开发完成再合入kubernetes/kubernetes的 master而不是把半成品直接合进主干。为什么不能直接依赖测试必须全绿与会者 Aaron 提出了一个自然的反问既然已经有测试体系为什么不能直接要求测试必须全绿才能合入来作为门禁现场的回答点出了当时的两难大量新特性测试不足甚至根本没有充分的测试A lot of the new features have inadequate testing项目需要按固定节奏持续发布We want to continue to release on a regular cadence。也就是说在特性直接落 master 的现状下测试绿不绿无法成为有效的提前门禁发布经理又无权拒绝于是压力全部积压到发布尾期。特性分支的两个边界条件讨论同时为特性分支方案划出了两条红线不能有大型的、单体式的特性分支we also cant have large monolithic feature branches。因为一个大型分支一旦合入可能导致其他并行开发的合入陷入rebase 地狱rebase hell互相阻塞。测试机器需要能够对非 master 分支运行测试。讨论认为当时的测试机制已经逐步成熟到可以对 master 之外的分支拉起测试Test machinery is getting to a point where it can use branches other than master拉起一个特性分支并对其跑测试不会太麻烦。落地时间窗口Brian Grant 明确提出这个改变必须在 1.10 或 1.11 版本周期内完成we have to do within either 1.10 or 1.11 release。这一时间预期与同期2018 特性与路线图议题相互呼应——该议题同样把 1.10 视为 KEP 流程等新机制的落地窗口见 feature-roadmap-2018.md 中Kubernetes 1.10 would be a great place的表述。两个核心担忧如何保护主干如何判断就绪讨论中有人总结了大家听到的两个核心担忧如何保护主线开发不受这些并行特性的影响How do you protect mainline development from these features going in?如何判断特性何时可以合入How do you know when theyre ready to go in?。围绕第二点现场给出了两个残酷的现实参照Node.js 社区声称测试覆盖率有 90% 以上而 Kubernetes当时连覆盖率测量都没有由于系统中各组件高度相互依赖一个变更合入后基本上不可能再撤回来its basically impossible to back changes out。这意味着合入前把关比合入后回滚要现实得多也反过来支撑了更早门禁的必要性。跨仓库视角来自 workload API 的真实尝试与教训Tim Hockinthockin把问题进一步推向工程现实在已经拆出 90 仓库的背景下特性分支如何跨仓库运作他建议先听听真正尝试过的人的经验——很多细节只能在小规模试验后再放大规模people are just going to have to try it at small scale and then at large scale。现场出现了最有价值的实证案例Jan 分享了 workload API 的升级经验。尝试把 workload API 从v1beta2升级到v1时确实在特性分支上做了试验最大的阻塞点是测试测试只会在 master 分支上自动运行不会自动跑在特性分支上tests werent running against the feature branch, only the master branch automatically由于测试跑不起来团队最终决定还是直接在 master 上做。这个案例直接印证了前面测试机制必须支持非 master 分支这一前提条件的决定性意义——CI 支撑不到位特性分支就是空谈。常见的脚进门模式与文档缺失thockin 还总结了社区里频繁出现的模式有人提交一个上万行10k line的巨型 PRreviewer 说请拆开对方拆开了但拆着拆着就忘了写文档最后文档在某个环节被遗漏。Brian Grant 对此的回应是最好能要求大家先写文档——也许这就是特性分支的准入条件之一maybe this is a criteria for feature branches。文档先行作为特性分支门槛的思路与同期 feature-workflow.md 讨论中测试计划与面向用户的文档总是太晚才出现应纳入 KEP 流程的共识一脉相承。分支粒度一个 KEP 一个分支还是特性开关Venezia 在会上提出了两个方向性问题是否每个 KEP 对应一个分支a branch per KEP能否像 Facebook 那样使用特性开关feature flags如果不行是彻底不可行还是仅仅很难Brian Grant 的回答很明确特性开关可用但需要巨大的纪律性——必须保证这些 flag 在整个代码中被正确且一致地使用it requires a huge amount of discipline to ensure those flags are used correctly and consistently对 API 类特性开关很容易做但对贯穿多个组件的特性threaded through components就很难一个 KEP 一个分支大致就是正确的粒度A branch per KEP is roughly the right level of granularity。关于特性分支和大 PR 有什么区别现场给出的答案是review 流程根本不适合巨型 PR。thockin 补充说对维护者而言把东西合进来并锁定lock them in更轻松只是不该锁定在主树上他还表示欣赏 Linux 内核的副手模型lieutenant model——即由若干子系统负责人分层管理合入。特性分支与 KEP 的对应关系Jdumars 用一个冰山比喻进一步阐述了粒度问题一个 KEP 可能代表三个 issue就像从冰山上凿下来的三块冰ice cubes而特性分支应当承载与这些 issue 全部相关的代码。这实际上给出了KEP → issues → 特性分支 → PR的完整追踪链条雏形与 feature-roadmap-2018.md 中PR 汇总到 issueissue 链接到 KEP首次实现从 PR 层面看清全局的钢铁主线steel thread设想完全吻合。合并策略之争rebase 还是 merge commit面对特性分支终究还是要像 PR 一样 rebase的质疑maru讨论转向了合并策略Jago 指出关键差异特性分支可以支持整个团队一起在上面工作这是单个 PR 做不到的关于能否用 merge commit 替代 rebasethockin 认为这个问题可以用技术手段解决甚至比造一个更好的 review 工具更有价值rebase 之所以痛苦一半原因是生成代码generated code另一半原因是模块化不良poor modularity——我们值得投入精力改善模块化来减少 rebaseBrian Grant 补充了一个重要的副作用视角无论特性分支还是把代码迁到其他仓库都是倒逼forcing function我们清理代码结构的机制。也就是说特性分支不仅是流程工具也是架构卫生的催化剂。工程支撑分支保护、bot、fork 与 SIG 所属组织讨论后半段聚焦怎么把特性分支真正跑起来的工程细节分支保护与问题追踪特性分支应当被保护protected——luxas 提出这一点避免误 push需要解决issue 该 filed 到哪个 commit/分支的对应问题。Brian Grant 推测kubernetes/kubernetes上的 issue 大多由贡献者提出讨论明确认为需要一个 bot 来自动化处理well definitely want a bot that automatically ...。fork 还是分支thockin 提出一个反向方案为什么不用 fork 而用分支现场给出的反驳是为其他用户的 fork 拉起测试更难its harder to get tests spun up for other users。随后有人提出了一个折中设想与其支持用户级 fork不如 fork 到由 SIG 拥有的组织orgs owned by sigs并确保这些 org 的 CI 配置完善。记录者注明我强烈点头表示这是可行的。矩阵扩张的担忧jgrafton 提出了一个很实际的顾虑特性分支会给已经庞大的Kubernetes 版本分支 × release 分支矩阵再增加一个维度。这个维度主要不是对 PR 而言而是对CI/periodic 任务而言——你需要跑的远不止 PR 测试。他还指出一个来自门禁特性gated features经验的事实门控特性跑测试的频率更低因此那些偶发、低概率的竞态 bug 更难暴露测试覆盖存在隐忧。测试归属问题与SIG 拥有 org相关jgrafton 进一步发问是否要求各 SIG 在所有特性分支上都拥有并维护自己的 e2e 测试还是他们只需关心 master这暴露了特性分支方案在测试治理上的未决问题。同时有人提醒不要把一个特性过分绑定到单一 SIG 的归属上因为一个特性可能横跨多个 SIGmulti-SIG 特性在 feature-workflow.md 中同样被强调为需要显式沟通的难点。与相邻议题的联动monolith、KEP 与发布管理这场讨论并非孤立的流程脑暴它与峰会当天其他议题形成了紧密的论证闭环与 monolith 拆分的联动90 仓库的现状说明项目已经事实上拆分但kubernetes/kubernetes主仓库仍是集成点见 breaking-up-the-monolith.md。特性分支与仓库拆分被 Brian Grant 视为殊途同归的两条倒逼清理路径要么用分支隔离要么用仓库隔离都能迫使模块边界清晰化。与 KEP 流程的联动KEP 在 2017 年底正处于从 Google Docs 向 PR/源码控制迁移的 Alpha 阶段见 feature-roadmap-2018.md一 KEP 一分支的粒度主张天然地把两者绑在一起——KEP 作为活文档定义做什么特性分支作为承载体定义代码在哪开发。与 PR 流程现状的对照当时主仓库的合入已经高度自动化需要 pass 所有 e2e 测试、拿到 reviewers/approvers 的批准见 pull-requests.md 中描述的合入门槛。特性分支的诉求正是在这套合入即上线的流程上再加一道前置缓冲。历史回响这场讨论在后续实践中的验证从本仓库保存的社区会议纪要201801-201807_Community_Meeting_Minutes.md可以看到这场讨论并非停留在纸面Server-side apply 就曾在特性分支上开发纪要中明确出现Work on feature-branch for Server-side apply的记录见该文件第 271 行附近同期还有feature branch work will continue through code freeze / 1.11 之前不会合回主线的记录见该文件第 953 行附近说明特性分支确实被用作跨 code freeze 延续工作的载体——这正是讨论中设想的用途之一该文件还记录了 1.11 尝试条件性缩短 code freeze、以稳定测试通过换取更多开发时间的实验见第 1241–1242 行附近与更早门禁、减少尾部救火的诉求一脉相承。需要说明的是以上属于仓库纪要中可查证的历史记录特性分支在 Kubernetes 后续版本中的最终形态与普及程度已超出本仓库所能证实的范围本文不作断言。结论与行动建议总结这场讨论形成的共识与待办可以归纳为以下几点特性分支是缓解发布救火的可选路径但前提是测试机制必须支持非 master 分支自动跑测试——workload API 的失败尝试证明了这一点是成败关键粒度以一个 KEP 一个分支为宜避免大型单体分支引发的 rebase 地狱特性开关feature flags只适合 API 类等局部特性跨组件特性慎用rebase 痛苦的根因是生成代码与模块化不足应借特性分支/仓库拆分之力改善模块化merge commit 方案值得用技术手段探索工程配套特性分支需要保护、需要 bot 自动化、需要明确 issue 归属SIG 所属 org 的 fork 加完善 CI 是比用户 fork 更优的试验方向对 CI/periodic 测试频率下降带来的竞态 bug 暴露风险要保持警惕文档先行把先写文档作为特性分支准入条件之一避免巨型 PR 拆分后文档丢失小规模试点先在少量项目上试验、汇报经验再放大到全项目1.10/1.11 为目标窗口。对社区成员而言启动特性分支试验的入口是先到 kubernetes-dev 邮件列表/讨论渠道联系由社区对接人帮你找到合适的负责人来推动流程落地原纪要给出的行动指引。感兴趣的读者可以继续阅读同目录下的 feature-workflow.md特性流程与 KEP 的并行讨论、breaking-up-the-monolith.md仓库拆分与模块化以及 feature-roadmap-2018.mdKEP 与 2018 路线图以完整还原 2017 年底 Kubernetes 社区在工程流程与治理上的整体思考脉络。【免费下载链接】communityKubernetes Community Documentation项目地址: https://gitcode.com/GitHub_Trending/com/community创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考