WordPress 插件和主題開發人員的分階段部署:避免“Clusterbug 發布”
已發表: 2020-12-23您還記得上次發布 WordPress 插件或主題的新版本以快速發現您錯誤地添加了一個新的主要錯誤,該錯誤會從您的測試序列裂縫中溜走嗎?
Yoast SEO 3.0 早在 2015 年就打破了許多網站。Elementor 3.0 今年也做了同樣的事情。 這些只是我在我們這個領域擁有 100 多名員工和專門的 QA 人員的出色公司中的兩個例子(不,它與 3.0 版本無關,但也許這是在您的軟件中跳過該版本的標誌; ))。
無論您是自學成才的編碼員或軟件工程師、獨立開發者,還是大型插件/主題商店的一員,我們都必須處理錯誤。 它是軟件開發中不可避免的一部分。
無論您實施了何種花哨的 CI/CD/測試自動化——您將永遠無法對其進行全部測試。 服務器配置的數量(PHP、MySql、緩存、Web 服務器)、WP 版本、插件和主題的組合……都是無窮無盡的。
這是違反直覺的。 您的產品越受歡迎和越穩定,發布可怕的“Clusterbug”的機會就越大,這會耗盡您的支持,可能會嚴重影響客戶的信任和忠誠度,並可能損害整體品牌聲譽。
雖然您無法避免錯誤,但您可以而且絕對應該盡可能地降低風險。
如果您有智能手機,您可能會注意到您的一些朋友會在您獲得 Android/iOS 更新的幾天、幾週甚至幾個月之前獲得更新。 這不是巧合,不,這不是針對你個人的。 這是一個名為 Staged Rollouts 的有意漸進式部署過程,可幫助 Apple 等公司向超過 10 億台設備提供主要軟件更新。
是的,十億!
如果必須同時向 15 億台移動設備推送實時更新,您是否能理解 Apple 的版本負責人所肩負的責任? 我不能。 我敢打賭,沒有一個理智的人會同意承擔這樣的責任。
那麼,分階段推出機制是如何工作的呢? 你怎麼能實現它? WordPress.org 還在等什麼? 這些是我將在下面介紹的主題。
什麼是 WordPress 插件和主題的分階段推出?
分階段推出允許您指定要推出新版本的網站的數量(或百分比)。 分階段推出機制使您能夠以有限的曝光率開始您的發布週期,然後在您監控支持和反饋的同時逐步增加它,從而為您和您的用戶建立對發布的信心。
分階段推出的好處是什麼?
您可以逐步發布版本,而不是冒著釋放潛在錯誤、與第三方插件/主題衝突甚至 UI/UX 問題而冒著整個安裝基礎的風險,從而最大限度地減少暴露於意外問題的人員和網站的數量。 一旦您解決了在推出過程中發現的所有問題和錯誤,您的絕大多數用戶將接觸到一個“成熟”且更穩定的版本。
我們使用滾動更新來確保我們新版本的質量。 如果新版本出現問題,我們可以快速識別它,並且只有一小部分用戶會受到影響。
SeedProd 創始人 John Turner
使用分階段發布是負責任地發佈軟件的最佳實踐——許多 WP 泡沫之外的公司(無論規模大小)都遵循這一過程。
WordPress 社區有很大的機會利用分階段部署,我稍後會談到。
Beta 計劃是否類似於分階段推出?
為您的 WordPress 產品設置一個 Beta 程序是一個很好的開始,但它遠沒有分階段推出那麼有效,而且它具有根本不同的目的和動態。
除非您的插件或主題非常受歡迎並且擁有龐大的社區,否則招募統計上足夠的 beta 組是非常具有挑戰性的,因為只有一小部分用戶有興趣加入。 即使你擅長招募一群像樣的 beta 測試人員,你也必須依靠他們的可用性和善意來測試產品,然後希望他們付出額外的努力來報告他們發現的問題。
你覺得有多少人會看透這整個過程? 不太多。
Beta 測試是一個預生產過程,在此過程中您的支持工作受到完全控制,測試人員預計會遇到 Beta 版本的問題。 因此,測試人員對質量的期望並不代表您的用戶群的普遍情緒。
此外,負責任的 Beta 程序會警告其測試人員避免在生產環境中使用 Beta 版本,因此 Beta 測試並不能真正模擬實時生產網站。
如何管理 WordPress 插件或主題的分階段發布?
作為我對 Staged Rollouts 研究的一部分,我有機會與 Amir Helzer 進行電子會議,並從他們 2 年多的使用 Staged Rollouts 和 WPML 和 Toolset 的經驗中學習,這些插件在超過 1,000,000 個 WordPress 網站上運行。
以下是 Amir 分享的關於他們的分階段部署實施的內容:
當網站安裝我們的任何插件時,我們會在 1 到 100 之間抽取一個隨機數並將其存儲在網站的數據庫中以供記憶。 這種方法基本上以隨機方式將網站分成 100 個箱。
當一個版本準備好上線時,它只會增量地可供單個選定的 bin 使用。 每天,我們都會在指定的 bin 中增加 5% 的網站在該版本的曝光率。 並在我們進行時修復和修補即將出現的問題。
為了使用更新版本使環境多樣化並避免重複出現相同的早期版本“受害者”,Amir 確認每個新版本都會首先進入不同的用戶群。
這種方法還意味著平均發布週期需要大約一個月才能為每個用戶提供。
人們需要一段時間才能在 WP Admin 中看到可用的新版本並更新他們的版本。 即使在他們這樣做之後,他們也可能需要幾天的時間才能發現問題。
鑑於我們的受眾規模,不可避免地,每個版本都會出現一些問題。 我們的主要目標是確保避免引入新問題,如果這樣做,我們有一個可靠的流程來解決這些問題。
發布週期確實很長,但即使在最壞的情況下,我們在測試中遺漏了一些瘋狂的錯誤,我們 95% 的用戶甚至沒有意識到所有的戲劇性,因為他們沒有接觸到發布直到穩定為止。
Amir 還強調了在發布之前與整個團隊同步的重要性,尤其是客戶支持和開發。 這樣,團隊成員可以額外關注因與正在進行的發布相關的問題而觸發的工單,目的是檢查、確認和修復有效問題並儘快發布補丁。
我們的團隊中有三個支持層。 第 1 層將查看問題,通過重現它來驗證它實際上是與插件發布相關的問題。 當一個案例似乎與新版本相關時,它會轉到第 2 層,這將調試問題以驗證它確實與版本相關,並在代碼中找到觸發問題的相關部分。 如果通過驗證,負責該代碼的開發人員將立即收到通知,以確定修復的優先級。
OnTheGoSystems 是一家擁有近 100 名員工的大公司,因此他們完善了分階段推出流程是有道理的。 但是,即使作為擁有一個支持層(您和您自己)的單一產品開發人員,Amir 的洞察力也可以告訴我們,為發布分配專用資源至關重要。 最好優先考慮與您的新版本相關的甚至“聞起來”的支持票,並儘可能減少新問題的曝光。
為什麼(幾乎)沒有支持分階段推出的插件或主題?
在準備撰寫本文時,我嘗試詢問社區誰在使用分階段推出,以便獲得有關他們的經驗、他們學到的東西等方面的反饋。
不出所料,我發現我的網絡中只有兩家 WordPress 公司已將分階段推出作為其發布週期的一部分。 許多開發人員甚至不知道這個概念,其餘的人不使用它,因為他們的分發解決方案不支持它(或者他們可能已經考慮過開發它並且沒有時間)。
大多數不通過 Freemius 銷售的插件和主題開發人員通過 EDD 或 WooCommerce 從他們的網站銷售,它們都不支持分階段推出。 那些通過 CodeCanyon 和 ThemeForest 等市場銷售的人也沒有開箱即用的解決方案,而且很可能永遠不會有。
即使是了解這個概念的開發人員也別無選擇,只能開發自己的機制來支持分階段推出。 這種基礎設施開發通常很難在產品公司中優先考慮。
訂閱並獲取我們的免費副本
WordPress 插件商業書籍
究竟如何在訂閱經濟中創造繁榮的 WordPress 插件業務。
與朋友分享
輸入您朋友的電子郵件地址。 我們只會通過電子郵件向他們發送這本書,童子軍的榮幸。
謝謝你的分享
太棒了——“The WordPress Plugin Business Book”的副本剛剛發送到. 想幫助我們更多地傳播信息嗎? 繼續,與您的朋友和同事分享這本書。
感謝訂閱!
- 我們剛剛將您的“The WordPress Plugin Business Book”副本發送到.
您的電子郵件中有錯字嗎? 單擊此處編輯電子郵件地址並再次發送。
分階段部署如何為您帶來商業優勢?
由於目前幾乎沒有人利用分階段推出,如果您開始使用分階段推出並在您的網站上適當地推銷它,讓訪問者知道您有負責任的發布週期,它肯定會給您帶來競爭優勢並增加對您產品的信任/品牌!
如果您從開發人員的角度分析市場,您會注意到許多開發人員密切關注他們的競爭對手,並且通常將他們的價格設置在垂直市場的價格範圍內,這導致競爭的 WordPress 產品在相同的價格範圍內提供類似的功能。
從買家的角度來看,這意味著購買哪種產品通常是一個折騰,因為它們都具有可比的功能和價格。 但是,當您評估幾個成本相同並且具有相同功能的插件時,您是否會傾向於使用提供分階段推出的產品,因為它知道其生產版本應該比競爭對手更穩定?
分階段推出可增強您對產品和業務的信心。 在分階段推出成為標準做法之前,您可以利用這一優勢(我真的希望他們這樣做)。
Freemius 現在支持分階段推出付費插件和主題
我們很高興在高級 WordPress 插件和主題生態系統中率先推出分階段部署。 我們的銷售合作夥伴現在可以安全、自信、可靠地發布更新,而對他們的用戶或支持/開發資源的影響最小。
我們知道主要版本有多麼具有挑戰性和令人傷腦筋,尤其是因為在“Clusterbug”版本發布後總是存在對您的品牌產生負面影響的潛在風險。
隨著分階段推出的到位,我們合作夥伴的品牌可持續性和可防禦性有了一個安全網,並減輕了與向大量用戶群發布相關的不必要的壓力。
這為我們合作夥伴的客戶帶來了好處。 當用戶購買通過 Freemius 銷售的產品時,他們現在可以確信自己選擇了由 Staged Rollouts 提供支持的解決方案,並且他們可以期待使用該機制的高級插件和主題發布更穩定的版本。
如果您使用 Freemius 進行銷售,以下是正確使用我們的分階段推出機制的方法。
Freemius 如何實施分階段部署?
每個激活許可證以解鎖高級插件或主題的網站都會在我們的數據庫中記錄。 我們所做的第一件事是引入一個新的last_served_update_version
屬性來存儲網站可用的最新產品版本。
然後,我們用兩個新屬性豐富了負責存儲發布數據的表: limit
、 uniques
。
當開發人員將某個版本標記為已發佈時,他們將收到以下對話框提示,允許他們設置具有活動許可證的網站的百分比(或數量),他們希望將付費版本推廣到:
如果他們設置了有限發布發布,系統將計算具有有效許可證的活躍網站總數,然後相應地設置發布的新limit
屬性。
最後,我們更新了網站調用的用於檢查是否有新版本的 API 端點,並引入了以下邏輯(以偽代碼形式):
latest_version = load latest version of product X If (website is on latest_version) return “no new version” If (last_served_update_version of website same as latest_version) return “no new version” If (latest_version is limited) If (latest_version is limited AND uniques >= limit) return “no new version” previous_version = load the previous version of product X If (previous_version is limited too AND uniques <= previous_version.uniques) If (website not using previous_version AND last_served_update_version different from previous_version) return “no new version” else If (random({true, false}) ) return “no new version” Set last_served_update_version of website to latest_version Increment uniques by 1 return latest_version
該算法確保:
- 發布的曝光根據設定的推出百分比進行限制。
- 如果之前的版本仍然是分階段的,即它從未暴露給整個安裝群,那麼收到之前分階段版本的網站將首先暴露給最新的分階段版本。
與 WPML 的分階段推出架構不同,該架構確保每個版本都將使用邏輯箱進入其安裝庫的不同子集,我們的實現依賴於隨機性。 因此,一個網站可能會在兩個連續的發布週期中獲得兩個早期版本。 但是,這種方法的好處是我們能夠向所有合作夥伴的客戶提供分階段部署,而無需推送 SDK 更新,這可能需要數月甚至數年才能傳播給所有客戶。
為什麼分階段部署對於 WordPress 的未來至關重要?
當我問阿米爾他們為 WPML 發布週期開發分階段部署的觸發因素是什麼時,這是他告訴我的:
3 年前,在 WordCamp Europe,我花時間與 WPML 客戶聊天,收集有關他們整體體驗的各種反饋。 我發現的第一大挫折是我們的客戶害怕更新插件,因為它可能會意外破壞他們的網站。
阿米爾·赫爾澤,
OnTheGoSystems(WPML,工具集)創始人
我絕對與此有關。
在更新插件和主題方面,我們在 Freemius 的內部政策是……根本不這樣做! 有兩個例外:如果存在已知的安全問題或我們網站需要的較新版本中可用的功能。
我們的更新政策是“血寫的”,因為發生了幾次錯誤的更新事件並導致了意想不到的頭痛和時間浪費,從而中斷了我們的運營和時間表。 是的,我們本可以通過暫存環境避免一些壓力,但是如果我們仍然想繼續更新到生產環境,這不會為我們節省時間和麻煩。
從那時起,WordPress 有了一些發展,現在我們可以在插件失敗時自動停用。 但是,這不適用於主題,停用我們網站的關鍵任務插件仍然是一個大問題。
底線是,如果我作為插件開發人員和一家幫助成千上萬的插件和主題開發人員發展業務的公司的首席執行官,我擔心每次我們更新網站上的插件或主題時都會破壞我們的網站,那麼這當然意味著大多數用戶對更新我們空間中的軟件沒有信心。
缺乏分階段推出讓我們和整個 WP 生態系統倒退,並為基於 SaaS 的競爭解決方案提供了相當大的優勢。 WiX 和 Shopify 用戶根本不需要考慮更新! 更新只是在後台為他們進行,他們的軟件始終是最新的、安全的和功能方面的。
缺乏分階段推出阻礙了整個 WP 生態系統,並為基於 SaaS 的解決方案提供了相當大的優勢。 WiX 和 Shopify 用戶不需要考慮軟件更新——它們只是在後台發生。Tweet
如果您觀看了上週的 State of the Word,WordPress 聯合創始人 Matt Mullenweg 顯然明白了最新軟件的重要性。 這是馬特對 WP 更新的願景:
… 允許您選擇加入 Core 的自動更新。 這是我們實現目標的第一步,讓您的 WordPress 基本上可以自我維護,當您可以設置它並忘記它時,它將在後台自動進行,並且對您的所有插件、主題和核心進行無憂更新。
我可以想像 WordPress 成為“一勞永逸”的唯一方法是軟件更新是否可以更加可靠和可信,而這只能通過分階段推出來實現。
WordPress.org:這是為插件和主題存儲庫引入分階段部署的方法
與我們的實現類似,WordPress.org 數據庫中的每個插件和主題版本都需要添加兩個新的元選項: limit
和uniques
。
可以在高級視圖中為登錄的所有者(也可能為其他提交者)公開limit
元選項編輯:
開發人員將有辦法控制每個版本的曝光,以及為下一個版本設置限制的能力。
由於 WordPress.org 不會為每個從 WordPress.org 接收更新的網站存儲結構化數據,而不是將網站“看到”的最新版本存儲在 WordPress.org 數據庫中,數據的存儲可以委託給網站. 這意味著'update_plugins'
瞬態和在檢查更新時發送到 WordPress.org API 的數據將需要使用last_served_update_version
進行豐富。
最後,WordPress.org 更新 API 端點可以使用我們用於 Freemius 分階段部署實施的相同邏輯來豐富。 該機制不依賴於 wp.org 數據庫中的last_served_update_version
,而是依賴於核心從網站發送的值。
輕輕鬆松,不是嗎?
讓我們恢復用戶點擊更新按鈕的信心
我們都希望看到 WordPress 成功並不斷發展壯大和更好!
有這麼多資源進入古騰堡,很明顯 WordPress 的領導層承認我們必須讓普通的非技術人員更容易訪問該平台。 問題是,只要軟件更新不可信,即使有古騰堡和我們可用的所有令人驚嘆的頁面構建器,一個非技術人員也會在他們第一次失敗的更新時跑到 Wix,我不能責怪他們。
我向 EDD 的創始人 Pippin Williamson、WooCommerce 首席執行官 Paul Maiorana 和 WordPress.org 團隊呼籲:我們有機會為更大的 WordPress 社區打造更加穩定的插件和主題生態系統。 讓我們讓用戶能夠以更少的恐懼和挫敗感來保持他們的軟件安全和最新。 雖然它在短期內可能看起來不是一個高優先級,但我相信從長遠來看,我們都會從中受益。