分享到

引言

在軟體開發中,測試傳統上被限定在與生產部署分離的開發和預釋出環境中。這種隔離的原因是為了最小化測試與生產流量同時執行時的效能影響,並減少破壞性更改影響生產環境的可能性。

儘管存在這些擔憂,但將部分測試在生產環境中完成的趨勢正在增長。這種策略,簡稱為生產環境測試 (TIP),可以幫助團隊更好地理解新程式碼將如何與它需要相容的實際系統和資料進行互動。

在本指南中,我們將探討在生產環境中測試軟體變更的理念。我們將介紹過去對生產測試持保留態度的一些歷史原因、使採納變得更具吸引力的變化,並討論它對開發速度和錯誤減少可能產生的一些好處。

什麼是生產環境測試?

生產環境測試是一種鼓勵開發者將部分或全部軟體測試推遲到程式碼部署到生產環境中的理念。但是,團隊為什麼要轉向生產環境測試呢?

乍一看,這個想法可能顯得反直覺,甚至危險。也許不足為奇的是,它並非沒有風險。然而,透過引入一種部署和測試策略,不僅可以更徹底地測試您的軟體,還可以幫助您構建一個更具彈性的生產環境,從而消除許多風險。

生產環境測試很有價值,因為它消除了因生產環境和測試環境之間的環境差異而產生的一類問題。您不再是在一個專用環境中進行測試,然後將透過測試的程式碼部署到生產環境,寄希望於其行為保持一致,而是直接在程式碼需要執行的地方進行測試。

採納生產環境測試理念的團隊關注點可總結如下:

  • 儘快將程式碼部署到生產環境: 這使您的團隊能夠儘早地在程式碼必須執行的環境中進行測試
  • 將程式碼部署與程式碼釋出解耦: 將部署過程與釋出變更的行為分離,使您在測試和啟用新功能時具有更大的靈活性
  • 使用真實資料進行測試: 資料庫模擬物件、樁或填充了虛擬記錄的資料庫無法準確複製您的程式碼需要適應的資料
  • 最小化變更的影響範圍: 如果您可以在測試和釋出期間限制和調整範圍,則可以更安全、有效地測試變更

生產環境測試有哪些風險?

許多人懷疑生產環境測試的收益是否能超過其成本。在我們繼續之前,讓我們談談這種策略的一些風險以及如何緩解它們。

缺陷風險

在生產環境中測試程式碼的主要擔憂是可能引入會影響使用者和服務的軟體缺陷。傳統軟體測試流程背後的理念是在程式碼晉升到生產環境之前,對其進行徹底審查並檢查已知弱點。

這種觀點有其優點,但實際情況往往並非如此清晰。組織在預釋出環境中執行的測試通常不能很好地近似程式碼在生產環境中將要處理的情況。複製環境,包括基礎設施和工作負載,並非易事,並且經常與實際生產系統不同步。

這導致的結果是,您在預釋出環境中測試的內容可能並不適用於您的程式碼釋出後的實際表現。此外,無論嘗試是否成功,都需要投入大量的精力、時間和基礎設施。

對即時系統的影響

一個密切相關的擔憂是新變更和測試過程本身可能對生產環境產生的影響。系統穩定性是大多陣列織的首要任務,因為它會影響服務的可用性和可訪問性,並損害使用者信任。

儘管部署到生產環境的任何程式碼都有可能影響運營,但仍有方法可以最大程度地減少潛在影響。實施控制以限制新程式碼接收的流量、設定主動備用基礎設施以及實施基於監控的擴縮容,是使此過程更安全的一些方法。這些緩解措施的優點在於,這些投入直接提高了您的生產系統對各種系統故障的彈性。

如何進行生產環境測試

生產環境測試究竟是如何進行的?在本節中,我們將討論組織為了在生產環境中可靠地測試程式碼而實施的一些最常用技術和策略。雖然不一定需要採納所有這些想法,但其中許多方法相互補充,可以作為更全面系統的一部分進行整合。

實施特性標誌系統

特性標誌是一種程式設計和釋出技術,它涉及到使功能易於從外部啟用或停用。其基本思想是將新功能封裝在條件邏輯中,該邏輯在執行前檢查配置變數的值。“標誌”或“切換”變數通常配置在外部儲存(如 Redis)中,組織可以根據需要輕鬆更改其值。

特性標誌是生產環境測試中的一個寶貴工具,因為它們允許您安全地部署程式碼,而不會影響生產系統的當前邏輯。新的程式碼路徑可以先停用,然後在準備好測試新程式碼時再啟用。特性標誌概念的許多實現都包含比“啟用”或“停用”更細粒度的控制,例如可以選擇為特定百分比的流量啟用、A/B 測試不同的邏輯,或僅在特定情況下選擇路徑。

透過使用特性標誌,您可以將程式碼以停用狀態部署到生產環境。您可以使用您的測試套件測試新的程式碼路徑,而生產流量繼續使用舊的邏輯。然後,您可以作為金絲雀釋出,透過緩慢增加新程式碼路徑接收的生產流量來逐步釋出程式碼,同時監控其影響。

使用 CI/CD 在生產基礎設施上部署和測試

關於生產環境測試的一個誤解是,認為測試必須在生產環境中完成。雖然支持者認識到在程式碼最終執行的環境中進行測試的價值,但並非所有測試都需要如此高的保真度,許多快速、有針對性的測試可以自動化,並作為程式碼部署前準備工作的一部分執行。

實現這一目標最簡單、最有效的方法是透過一個精心調優的 CI/CD 流水線。CI/CD,即持續整合和持續交付或部署,是一個系統,它在程式碼新增到儲存庫時自動測試新程式碼。一旦測試套件成功透過,該流水線(持續交付)允許開發人員透過點選按鈕部署變更,而持續部署則自動部署所有成功測試的程式碼。

CI/CD 在生產環境測試之外還有許多好處。對於我們所描述的系統,流水線作為部署過程的自動化部分,目標是在生產環境中部署和測試。雖然像單元測試這樣的簡單測試可以獨立完成,但像整合測試這樣更復雜的階段,理想情況下應該透過將程式碼部署到生產基礎設施並在那裡進行測試來完成。這允許您的程式碼在最終執行的相同執行上下文下,針對它將互動的實際服務進行測試。

CI/CD 流水線有助於增強對新變更的信心,並緩解因程式碼快速部署到生產環境而產生的焦慮。結合特性標誌,開發團隊可以相信程式碼的某些方面已經過審查,然後可以控制如何進行更大量的測試。

配置您的服務以允許暗啟動

暗啟動是一種部署軟體變更並使用真實流量進行測試的方法,而不會對使用者造成影響。其理念是映象生產流量,並將重複請求傳送到您新部署的程式碼,以便您可以確保它既能正確執行,又能處理實際的生產負載。

暗啟動可能相當複雜,因為它要求您在應用程式的多個例項上重放現有流量,而不會導致影響測試合法性的減速。即時複製請求的替代方案是從事件日誌或其他來源回放先前的請求。此策略要求您捕獲初始請求的所有相關上下文。

暗啟動的好處是,它允許您看到程式碼的功能,就好像它已經發布給使用者一樣。透過新程式碼執行流量的結果永遠不會顯示給使用者,但它們可以提供關於您的程式碼行為以及需要考慮哪些型別條件的資訊。一旦您測試了一個暗啟動版本的應用程式,考慮到它已經面臨過這些壓力,您就可以對其在生產環境中的表現相當有信心了。

實施強大的監控和指標收集

除了部署和釋出期間執行的核心測試之外,還必須建立系統,以便在程式碼投入生產後繼續監控其行為。可以實施各種相關技術,幫助您長期瞭解服務執行狀況,從而在新程式碼導致行為變化時更快地發現異常。

監控和指標跟蹤是您可以用來了解服務在不同時間段和條件下如何執行的基本工具。新變更可能會產生短期內難以發現的副作用,但隨著時間的推移可能會變得明顯。監控和指標可以幫助將這些行為變化與特定版本關聯起來。

生產環境測試如何影響資料庫?

生產環境測試中最複雜的方面之一是找出一種有效的方式來執行與資料庫互動的測試。雖然可以讓新程式碼從不同的資料來源讀取和寫入,但這又一次引入了針對複製不佳的環境進行測試的可能性。

更好但更難實現的選擇是使用您的生產資料庫進行測試。這可能很難實施,特別是如果您的資料庫模式和工具從一開始就沒有為此可能性進行配置,但它提供了了解您的程式碼在釋出時將如何行為的最佳機會。

允許您的新程式碼從生產資料庫讀取資料是相當直接的。只要測試不會導致嚴重的讀取爭用,它就不應顯著影響資料庫的生產職責,並且您的生產資料也不會有危險。

然而,測試您的程式碼如何執行寫入操作則有點棘手。最直接的測試方法是在生產資料庫中建立專用的測試使用者,以便您的新程式碼可以在不觸及真實使用者資料的情況下操作資料。這仍然可能是一個相當令人擔憂的提議,因為測試操作將與來自您的活躍程式碼的真實資料同時執行。

結論

生產環境測試可能難以實施,並且對於現有專案來說可能需要進行許多更改。然而,採用一個可以在實際環境中測試程式碼真實行為的系統所帶來的好處,再怎麼強調也不為過。測試旨在識別錯誤並增強對軟體的信心,這兩個目標在非代表性環境中很難完全實現。

通過了解這種方法所涉及的挑戰,您可以評估它與您的組織工作方式的契合度。生產環境測試是一項權衡取捨的工作,您的成功可能很大程度上取決於您願意並能夠投入到該過程中的精力。雖然這不一定是一個容易的調整,但其優勢可以在長期內為您帶來益處。

關於作者
Justin Ellingwood

Justin Ellingwood

Justin 自 2013 年以來一直撰寫有關資料庫、Linux、基礎設施和開發者工具的文章。他目前與妻子和兩隻兔子居住在柏林。他通常不必以第三人稱寫作,這讓所有相關方都鬆了一口氣。
© . This site is unofficial and not affiliated with Prisma Data, Inc.