AMP 版本發佈排程
AMP 每週二會將新版本推送至所有 AMP 網頁。一旦 AMP 的變更合併到 amphtml 存放庫的主要分支,通常需要 1-2 週的時間,變更才會對所有使用者生效。
AMPHTML 驗證工具有其自己的發佈排程
發佈管道
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 版和 Experimental 版管道
Beta 版和Experimental 版管道是 AMP 下一個 Stable 發佈版本的預先發佈候選版本。每週二 (除了有發佈凍結期的週外),上週的 每夜版 會升級到開發人員選擇加入的 beta 和 experimental 管道。在驗證這些管道中未引入任何功能或效能衰退的一天期間後,我們會在週三將此發佈版本升級到一小部分的流量。然後,此相同的發佈版本會在下週二升級到 stable 管道。
可以選擇加入這些管道。請參閱 [developing.md] 中的選擇加入章節以瞭解詳細資訊。
選擇加入 Beta 版管道的目的是為了
- 測試和體驗即將發佈的 AMP 執行階段版本
- 在品質保證 (QA) 中使用,以確保您的網站與下一個 AMP 版本相容
Experimental 版管道的目的是為了
- 測試和體驗尚未向所有使用者提供的全新功能
- 在品質保證 (QA) 中使用,以確保您的網站與仍在開發中的 AMP 即將推出的功能相容
Experimental 版管道 可能較不穩定,並且可能包含尚未向所有使用者提供的功能。
長期穩定版 (LTS)
lts 發佈管道提供先前 stable 建構版本,間隔為一個月。在每個月的第二個星期一,目前的 stable 發佈版本會升級為 lts。不建議所有 AMP 發佈商使用此管道。它旨在讓希望以較低頻率對其網站執行 QA 週期的發佈商,可以透過將特定網頁選擇加入 lts 管道來達成 (請參閱 lts 讀我檔案)。
如果該月的第二個星期一適逢假日,則升級將在發佈凍結期結束後執行。
ampproject/amphtml
的 HEAD
落後長達七週。請參閱關於判斷您的變更是否包含在發佈版本中章節,以驗證變更是否已準備好用於您選擇的發佈週期。判斷您的變更是否包含在發佈版本中
Type: Release GitHub 議題用於追蹤目前和過去發佈版本的狀態;從初始版本,到透過 experimental/beta 管道進行測試,到最終透過 stable 和 lts 管道發佈。關於發佈版本的公告會在 AMP Slack #release 頻道 (註冊 Slack) 上發佈。
您可以使用下列其中一種方式判斷特定發佈版本中包含哪些變更
- 每個發佈版本的 Type: Release GitHub 議題將包含指向特定發佈頁面的連結,其中列出該發佈版本中包含的變更。
- 當 PR 進入每週或 lts 發佈版本時,會將 PR Use: In Beta / Experimental、PR Use: In Stable 和 PR Use: In LTS 標籤新增至 PR。發佈版本的建立時間與標籤的新增時間之間可能會存在延遲。
發佈頻率
我們在發佈頻率方面刻意謹慎。
在判斷我們應該多久向所有人推送新版本的 AMP 時,我們必須權衡許多因素,包括
- 數百萬個網站/數十億個使用 AMP 建構的網頁的穩定性
- 當我們推送新版本時可能發生的快取失效
- 快速推出新功能的期望
在考量所有這些因素後,我們得出了 1-2 週的推送週期。到目前為止,我們發現這是一個合理的折衷方案,但我們將繼續評估所有這些因素,並可能在未來進行變更。
詳細排程
我們盡力嚴格遵守此排程,但複雜情況可能會導致延遲。您可以在 Type: Release GitHub 議題和 AMP Slack #release 頻道 (註冊 Slack) 中追蹤有關任何發佈版本的最新狀態。
- 每週工作日晚上:會自動建立新的 每夜版 建構版本,並發佈到 AMP 每夜版管道。
- 週二 @ 太平洋時間上午 11 點:從最近已知的良好每夜版管道發佈版本建立新的 experimental 和 beta 發佈版本,並提供給選擇加入 AMP Experimental 版管道或 AMP Beta 版管道 的使用者。
- 週三:我們會檢查 Experimental 版管道和 Beta 版管道 使用者的錯誤報告,如果一切看起來正常,我們會將 beta 推送到 1% 的 AMP 網頁
- 週四至週一:我們會繼續監控 Experimental 版管道和 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 認為程式碼庫穩定性特別重要的其他情況。
在所有情況下 (緊急情況除外),發佈凍結期將至少提前一個月宣佈。
請注意,除非另有公告,否則發佈凍結期並不表示程式碼凍結。程式碼仍然可以在發佈凍結期期間編寫、審查和合併。