AMP 發佈排程

發佈管道
判斷您的變更是否包含在發佈版本中
發佈節奏
- 詳細排程
- 發佈凍結期

AMP 的新版本每週二都會推送至所有 AMP 頁面。一旦 AMP 的變更合併到 amphtml 儲存庫的主要分支中，通常需要 1-2 週的時間，變更才會對所有使用者生效。

發佈管道

AMP 執行階段和擴充功能透過各種不同的發佈管道提供。每個管道都為開發人員和 AMP HTML 專案本身服務。請參閱發佈節奏章節，以更詳細地了解 ampproject/amphtml 儲存庫中的程式碼如何以及何時進入發佈版本。

若要判斷 PR 是否已包含在以下任何發佈管道中，請尋找 GitHub 標籤 PR Use: In Canary、PR Use: In Production 或 PR Use: In LTS（詳情請參閱判斷您的變更是否包含在發佈版本中章節）。

每夜版

每夜版發佈管道（顧名思義）每週工作日晚上更新。此程序是自動化的，並且不保證任何給定的每夜版發佈版本都沒有錯誤或其他問題。每天晚上午夜（太平洋時間）過後，會選取當天最後一個「綠色」提交作為發佈截止點。綠色建置表示所有自動化測試都已在該建置上通過。

每夜版提供了一種機制，可以快速偵測和解決問題，並在問題到達流量更大的每週發佈管道之前解決。它還有助於減少受新引入問題影響的使用者數量。

可以選擇加入 每夜版管道，以測試過去幾天合併的提取請求。請參閱 [developing.md] 中的選擇加入章節以了解詳情。

每週版

每週發佈管道被視為主要的「常青」發佈管道。每週，前一週的 beta 發佈版本會升級為 stable 發佈管道，而前一週的最後一個 每夜版 發佈版本會升級為 experimental 和 beta 發佈管道（請參閱詳細排程）。

在建立發佈版本時，使用了兩組建置組態：canary 組態和 production 組態。experimental 和 beta 發佈管道是從同一個提交建置的。但是，experimental 管道使用 canary 組態，而 beta 管道使用 production 組態。canary 組態啟用可能在 production 中關閉的實驗性元件和功能。可以透過實驗頁面選擇加入 experimental 或 beta 管道。

stable 發佈管道使用 production 組態建置，並提供給大多數 AMP 流量。由於 beta 發佈管道也是從 production 組態建置的，因此它代表了將在下週成為 stable 的確切建置版本（有可能進行揀選以修復最後一刻的問題；請參閱貢獻程式碼）。

Beta 版和實驗性管道

Beta 版和實驗性管道是 AMP 下一個穩定發佈版本的預發佈候選版本。每個星期二（除了有發佈凍結期的週），上週的 每夜版 會升級為開發人員選擇加入的 beta 和 experimental 管道。在 1 天的期間內，我們驗證這些管道中沒有引入任何功能或效能衰退後，我們會在星期三將此發佈版本升級到一小部分流量。然後，這個相同的發佈版本將在下週二升級到 stable 管道。

可以選擇加入這些管道。請參閱 [developing.md] 中的選擇加入章節以了解詳情。

選擇加入Beta 版管道的目的在於

測試和體驗即將發佈的 AMP 執行階段版本
在品質保證 (QA) 中使用，以確保您的網站與下一個 AMP 版本相容

實驗性管道的目的在於

測試和體驗尚未向所有使用者提供的全新功能
在品質保證 (QA) 中使用，以確保您的網站與仍在開發中的 AMP 即將推出的功能相容

實驗性管道可能較不穩定，並且可能包含尚未向所有使用者提供的功能。

長期穩定版 (lts)

lts 發佈管道為一月間隔提供先前的 stable 建置版本。在每個月的第二個星期一，目前的 stable 發佈版本會升級為 lts。不建議所有 AMP 發佈商都使用此管道。它提供的目的是讓希望較不頻繁地對其網站執行 QA 週期發佈商，可以透過將特定網頁選擇加入 lts 管道來執行 QA 週期（請參閱 lts 讀我檔案）。

如果每個月的第二個星期一適逢假日，則升級將在發佈凍結期結束後執行。

使用 lts 發佈管道的發佈商不應使用新推出的功能。由於週期較長，lts 發佈版本可能比 ampproject/amphtml 的 HEAD 落後多達七週。請參閱判斷您的變更是否包含在發佈版本中章節，以驗證變更是否已準備好用於您選擇的發佈週期。

判斷您的變更是否包含在發佈版本中

Type: Release GitHub 議題用於追蹤目前和過去發佈版本的狀態；從初始版本，到透過 experimental/beta 管道進行測試，到最終透過 stable 和 lts 管道發佈。有關發佈版本的公告會在 AMP Slack #release 管道上發佈（註冊 Slack）。

您可以使用以下其中一種方法判斷給定發佈版本中包含哪些變更

每個發佈版本的 Type: Release GitHub 議題將包含指向特定發佈頁面的連結，其中列出了該發佈版本中包含的變更。
PR Use: In Beta / Experimental、PR Use: In Stable 和 PR Use: In LTS 標籤會在 PR 進入每週或 lts 發佈版本時新增至 PR。在建立發佈版本和新增標籤之間可能會有一段延遲。

發佈節奏

我們在發佈節奏方面非常謹慎。

在判斷我們應該多久向所有人推送新版本的 AMP 時，我們必須權衡許多因素，包括

使用 AMP 建置的數百萬個網站/數十億個頁面的穩定性
當我們推送新版本時可能發生的快取失效
快速推出新功能的渴望

在考慮所有這些因素後，我們得出了 1-2 週的推送週期。到目前為止，我們發現這是一個合理的折衷方案，但我們將繼續評估所有這些因素，並可能在未來進行變更。

詳細排程

我們盡力嚴格遵守此排程，但複雜情況可能會導致延遲。您可以在 Type: Release GitHub 議題和 AMP Slack #release 管道（註冊 Slack）中追蹤有關任何發佈版本的最新狀態。

每週工作日晚上：自動切割並發佈新的 每夜版 建置版本到 AMP 每夜版管道。
星期二 @ 太平洋時間上午 11 點：從最近已知的良好每夜版管道發佈版本建立新的 experimental 和 beta 發佈版本，並提供給選擇加入 AMP 實驗性管道或 AMP Beta 版管道的使用者。
星期三：我們檢查實驗性管道和Beta 版管道使用者的錯誤報告，如果一切看起來正常，我們會將 beta 推送至 1% 的 AMP 頁面
星期四至星期一：我們繼續監控實驗性管道和Beta 版管道使用者以及具有 experimental/beta 建置版本的 1% 頁面的錯誤率和錯誤報告
下週二：beta 發佈版本完全升級為 stable（即，所有 AMP 頁面現在都將使用此發佈版本）

發佈凍結期

在某些情況下，我們會跳過 AMP 發佈到生產環境，這稱為發佈凍結。

如果宣布第 N 週為期一週的發佈凍結

前一週的 stable 發佈版本將額外保留一週，即在第 N 週不會像往常一樣升級新的發佈版本到 stable。
但是，新的 beta 和 experimental 發佈版本將在凍結週（第 N 週）期間建立。
正常排程將在第 N+1 週恢復，即來自第 N 週的 experimental/beta 發佈版本在第 N+1 週升級為 stable。此外，新的 experimental/beta 發佈版本在第 N+1 週建立，並將在第 N+2 週升級為 stable。
如果在第 N-1 週升級的 stable 發佈版本原定於第 N 週升級為 lts，則現在將在第 N+1 週的星期一升級為 lts。
每夜版發佈版本仍會產生和升級，因為它們是完全自動化的。

發佈凍結可能因以下原因而發生

沒有足夠的人員可以將 AMP 發佈版本推送至 stable 並監控它。目前，大多數執行 AMP 發佈的人員都位於美國，因此通常會是美國主要節假日的週，例如獨立日（7 月 4 日）、感恩節（11 月的第四個星期四）、聖誕節（12 月 25 日）和新年除夕/元旦（12 月 31 日/1 月 1 日）。
緊急情況，例如由技術指導委員會 (TSC) 或執行發佈的人員確定的安全性或隱私問題。
TSC 確定程式碼庫穩定性被認為特別重要的其他情況。

在所有情況下，除了緊急情況外，發佈凍結將至少提前一個月宣布。

請注意，除非另有宣布，否則發佈凍結並不表示程式碼凍結。程式碼仍可以在發佈凍結期間編寫、審查和合併。