Kubernetes 發佈週期

將增強功能、問題和 PR 定位到發佈里程碑

本文檔著重於需要建立針對特定發佈里程碑的增強功能、問題或 Pull Request 的 Kubernetes 開發人員和貢獻者。

• TL;DR (太長不看)
  • 正常開發 (第 1-11 週)
  • 程式碼凍結 (第 12-14 週)
  • 發佈後 (第 14 週以後)
• 定義
• 發佈週期
• 從里程碑中移除項目
• 將項目新增至里程碑
  • 里程碑維護者
  • 功能新增
  • 問題新增
  • PR 新增
• 其他必要標籤
  • SIG 負責人標籤
  • 優先順序標籤
  • 問題/PR 類型標籤

將增強功能、問題和 Pull Request 導入 Kubernetes 發佈的流程跨越多個利害關係人

• 增強功能、問題和 Pull Request 的擁有者
• SIG 領導階層
• 發佈團隊

工作流程和互動的資訊如下所述。

作為增強功能、問題或 Pull Request (PR) 的擁有者，您有責任確保符合發佈里程碑的要求。如果需要更新，自動化系統和發佈團隊將會與您聯繫，但若無作為可能會導致您的工作從里程碑中移除。當目標里程碑是先前的發佈時，存在額外的要求 (請參閱cherry pick 流程以取得更多資訊)。

TL;DR (太長不看)

如果您希望您的 PR 被合併，它需要以下必要的標籤和里程碑，此處以 Prow /commands 指令表示，以新增它們

正常開發 (第 1-11 週)

• /sig {name}
• /kind {type}
• /lgtm
• /approved

程式碼凍結 (第 12-14 週)

• /milestone {v1.y}
• /sig {name}
• /kind {bug, failing-test}
• /lgtm
• /approved

發佈後 (第 14 週以後)

返回「正常開發」階段要求

• /sig {name}
• /kind {type}
• /lgtm
• /approved

現在合併到 1.y 分支是透過 cherry pick，經由發佈管理員核准。

過去，針對以里程碑為目標的 Pull Request，有一個開啟相關 GitHub issue 的要求，但現在已不再是這種情況。功能或增強功能實際上是 GitHub issue 或 KEP，它們會引導至後續的 PR。

一般標籤流程在各種類型的成品中應保持一致。

定義

• issue 擁有者：建立者、受讓人以及將 issue 移至發佈里程碑的使用者

• 發佈團隊：每個 Kubernetes 發佈都有一個團隊執行專案管理任務，如此處所述。

  與任何給定發佈相關聯的團隊的聯絡資訊可以在此處找到。

• Y 天：指營業日

• 增強功能：請參閱「我的東西是增強功能嗎？」

• 增強功能凍結：KEP 必須完成的截止日期，以便增強功能成為目前發佈的一部分

• 例外請求：請求特定增強功能延長截止日期的流程

• 程式碼凍結：最終發佈日期前約 4 週的期間，在此期間，只有關鍵錯誤修復程式會合併到發佈中。

• 修剪：如果增強功能未完全實作或被認為不穩定，則從發佈里程碑中移除增強功能的流程。

• 發佈里程碑：語意版本字串或GitHub 里程碑，指的是發佈 MAJOR.MINOR vX.Y 版本。

  另請參閱發佈版本控制。

• 發佈分支：為 vX.Y 里程碑建立的 Git 分支 release-X.Y。

  在 vX.Y-rc.0 發佈時建立，並在發佈後維護約 12 個月，並包含 vX.Y.Z 修補程式發佈。

  注意：1.19 及更新版本獲得 1 年的修補程式發佈支援，而 1.18 及更早版本獲得 9 個月的修補程式發佈支援。

發佈週期

Kubernetes 發佈目前大約每年發生三次。

發佈流程可以認為有三個主要階段

• 增強功能定義
• 實作
• 穩定化

但實際上，這是一個開放原始碼和敏捷專案，功能規劃和實作始終在進行中。 鑑於專案規模和全球分散的開發人員基礎，不依賴尾隨的穩定化階段，而是採用持續整合測試至關重要，這可確保專案始終穩定，以便將個別提交標記為已破壞某些東西。

透過整年的持續功能定義，某些項目組合將浮現，以針對給定的發佈。 增強功能凍結 在發佈週期開始約 4 週後開始。 到此時，針對給定發佈的所有預期功能工作都已在適當的規劃成品中定義，並與發佈團隊的 增強功能負責人 協調。

在增強功能凍結之後，追蹤 PR 和 issue 上的里程碑非常重要。 里程碑中的項目用作完成發佈的清單。 在 issue 上，里程碑必須透過 SIG 的分類正確應用，以便 發佈團隊 可以追蹤錯誤和增強功能 (任何與增強功能相關的 issue 都需要里程碑)。

有一些自動化機制可以協助自動將里程碑指派給 PR。

此自動化目前適用於以下儲存庫

• kubernetes/enhancements
• kubernetes/kubernetes
• kubernetes/release
• kubernetes/sig-release
• kubernetes/test-infra

在建立時，針對 master 分支的 PR 需要人工提示他們可能希望 PR 針對哪個里程碑。 一旦合併，針對 master 分支的 PR 會自動應用里程碑，因此從那時起，人工管理該 PR 的里程碑就變得不太必要。 針對發佈分支的 PR，里程碑在建立 PR 時會自動應用，因此永遠不需要人工管理里程碑。

任何其他應由發佈團隊追蹤且不屬於該自動化範圍的工作都應應用里程碑。

實作和錯誤修復在整個週期中持續進行，但在程式碼凍結期間達到頂峰。

程式碼凍結 在第 ~12 週開始，並持續約 2 週。 在此期間，只有關鍵錯誤修復程式會被接受進入發佈程式碼庫。

程式碼凍結後和大約發佈前有兩週的時間，在此期間，所有剩餘的關鍵問題都必須在發佈前解決。 這也為文件最終確定提供了時間。

當程式碼庫足夠穩定時，master 分支會重新開放以進行一般開發，並開始在那裡進行下一個發佈里程碑的工作。 目前發佈的任何剩餘修改都會從 master cherry pick 回到發佈分支。 發佈是從發佈分支建置的。

每個發佈都是更廣泛的 Kubernetes 生命週期的一部分

從里程碑中移除項目

在深入探討將項目新增至里程碑的流程之前，請注意

發佈團隊的成員可能會從里程碑中移除 issue，如果他們或負責的 SIG 確定 issue 實際上並未阻礙發佈，並且不太可能及時解決。

發佈團隊的成員可能會基於以下任何或類似原因從里程碑中移除 PR

• PR 可能會破壞穩定性，並且不需要解決阻礙問題
• PR 是新的、延遲的功能 PR，並且未經過增強功能流程或例外流程
• 沒有負責的 SIG 願意承擔 PR 的所有權並解決與之相關的任何後續 issue
• PR 未正確標記
• PR 上的工作已明顯停止，且交付日期不確定或延遲

雖然發佈團隊的成員將協助標記和聯繫 SIG，但提交者有責任對 PR 進行分類，並從相關 SIG 獲得支援，以保證由 PR 引起的任何損壞都將迅速解決。

在需要額外行動的情況下，發佈團隊將透過以下管道嘗試人對人升級

• 在 GitHub 中評論，並根據 issue 類型提及 SIG 團隊和 SIG 成員
• 向 SIG 郵件列表發送電子郵件
  • 使用來自 社群 SIG 列表 的群組電子郵件地址進行啟動
  • 選擇性地直接針對 SIG 領導階層或其他 SIG 成員
• 向 SIG 的 Slack 頻道發送訊息
  • 使用來自 社群 SIG 列表 的 slackchannel 和 SIG 領導階層進行啟動
  • 選擇性地直接 "@" 提及 SIG 領導階層或其他成員的 handle

將項目新增至里程碑

里程碑維護者

milestone-maintainers GitHub 團隊的成員受託負責在 GitHub 成品上指定發佈里程碑。

此群組由 SIG Release 維護，並有來自各個 SIG 領導階層的代表。

功能新增

功能規劃和定義如今有多種形式，但一個典型的範例可能是在 KEP 中描述的大型工作，以及 GitHub 中相關的任務 issue。 當計畫達到可實作的狀態且工作正在進行中時，增強功能或其部分會透過建立 GitHub issue 並使用 Prow "/milestone" 指令標記它們來針對即將到來的里程碑。

在發佈週期的前約 4 週，發佈團隊的增強功能負責人將透過 GitHub、Slack 和 SIG 會議與 SIG 和功能擁有者互動，以收集所有必要的規劃成品。

如果您有要針對即將到來的發佈里程碑的增強功能，請開始與您的 SIG 領導階層以及該發佈的增強功能負責人進行對話。

問題新增

Issue 會透過 Prow "/milestone" 指令標記為針對里程碑。

發佈團隊的 錯誤分類負責人 和整個社群會監看傳入的 issue 並對其進行分類，如貢獻者指南中關於 issue 分類 的章節所述。

使用里程碑標記 issue 可讓社群更好地了解何時觀察到 issue 以及社群認為必須在何時解決 issue。 在程式碼凍結期間，必須設定里程碑才能合併 PR。

PR 不再需要開啟的 issue，但開啟的 issue 和相關的 PR 應具有同步的標籤。 例如，如果高優先順序錯誤 issue 僅標記為較低優先順序，則其相關的 PR 可能無法合併。

PR 新增

PR 會透過 Prow "/milestone" 指令標記為針對里程碑。

如上所述，這是程式碼凍結期間的阻礙性要求。

其他必要標籤

以下是標籤及其用途和目的的列表。

SIG 負責人標籤

SIG 負責人標籤定義了如果里程碑 issue 停滯不前或需要額外關注時，我們將升級的 SIG。 如果在升級後沒有更新，則 issue 可能會自動從里程碑中移除。

這些是使用 Prow "/sig" 指令新增的。 例如，若要新增指示 SIG Storage 負責的標籤，請評論 /sig storage。

優先順序標籤

優先順序標籤用於在將 issue 移出發佈里程碑之前確定升級路徑。 它們也用於確定發佈是否應因 issue 的解決方案而被封鎖。

• priority/critical-urgent：永遠不要自動移出發佈里程碑；透過所有可用的管道持續升級到貢獻者和 SIG。
  • 被視為阻礙發佈的 issue
  • 在程式碼凍結期間，需要 issue 擁有者每天更新
  • 如果直到次要發佈後才發現，則需要修補程式發佈
• priority/important-soon：升級到 issue 擁有者和 SIG 負責人；在幾次不成功的升級嘗試後移出里程碑。
  • 不被視為阻礙發佈的 issue
  • 不需要修補程式發佈
  • 在程式碼凍結時，經過 4 天的寬限期後，將自動移出發佈里程碑
• priority/important-longterm：升級到 issue 擁有者；在 1 次嘗試後移出里程碑。
  • 甚至比 priority/important-soon 更不緊急/關鍵
  • 比 priority/important-soon 更積極地移出里程碑

問題/PR 類型標籤

Issue 類型用於協助識別隨著時間推移進入發佈的變更類型。 這可能讓發佈團隊更好地了解在更快的發佈節奏下我們會錯過哪些類型的 issue。

對於以發佈為目標的 issue，包括 Pull Request，必須設定以下 issue 類型標籤之一

• kind/api-change：新增、移除或變更 API
• kind/bug：修復新發現的錯誤。
• kind/cleanup：新增測試、重構、修復舊錯誤。
• kind/design：與設計相關
• kind/documentation：新增文件
• kind/failing-test：CI 測試案例持續失敗。
• kind/feature：新功能。
• kind/flake：CI 測試案例顯示間歇性失敗。