簡介
在軟體開發中，傳統上測試會被劃分到與生產部署分離的開發和預備環境中。這種區隔背後的理由，是為了盡可能降低與生產流量同時執行測試的效能衝擊，並減少造成破壞性變更影響生產環境的可能性。
儘管有這些考量，但越來越多人傾向於在生產環境中完成部分測試。這種策略簡稱為生產環境測試 (testing in production, TIP)，可以幫助團隊更了解新程式碼將如何與實際系統和資料互動，並與之相容。
在本指南中，我們將探討在生產環境中測試軟體變更的想法。我們將涵蓋過去不願意進行生產環境測試的一些歷史原因、使採用更具吸引力的變化，並討論它可能對開發速度和錯誤減少帶來的一些好處。
Prisma Data Platform 可以協助簡化在生產環境中存取資料庫的流程。如果您使用 Prisma Client 來管理資料庫連線，Prisma Data Platform 或許可以協助您更輕鬆地管理生產工作負載。
什麼是生產環境測試？
生產環境測試是一種理念，鼓勵開發人員將部分或全部軟體測試延後到程式碼部署到生產環境後再進行。但團隊為什麼想要轉向生產環境測試呢？
乍看之下，這個想法似乎違反直覺，甚至很危險。或許不令人意外，它並非沒有風險。然而，許多危險可以透過導入部署和測試策略來消除，該策略不僅能更徹底地測試您的軟體，還能讓您建置更具彈性的生產環境。
生產環境測試很有價值，因為它可以消除一類因生產環境和測試環境之間的環境差異而發生的問題。您不再是在專用環境中進行測試，然後部署通過測試的程式碼到生產環境，並希望其行為保持一致，而是改為在程式碼需要執行的環境中進行測試。
那些採用生產環境測試理念的人的重點可以歸納如下：
- 盡快將程式碼部署到生產環境： 這讓您的團隊能夠在程式碼必須執行的環境內儘早測試程式碼
- 將部署程式碼與發布程式碼解耦： 將部署程序與發布變更的動作分開，讓您在測試和啟用新功能時有更大的彈性
- 使用真實資料進行測試： 資料庫模擬或 Stub 以及填滿虛擬記錄的資料庫，無法準確複製您的程式碼必須容納的資料
- 盡量縮小變更的影響範圍： 如果您可以在測試和發布期間限制和調整範圍，就能更安全有效地測試變更
與生產環境測試相關的風險有哪些？
許多人懷疑生產環境測試的好處是否能超過成本。在我們繼續討論之前，讓我們先來談談這種策略的一些風險，以及如何降低這些風險。
缺陷風險
在生產環境中測試程式碼的主要考量，是可能會導入軟體缺陷，進而影響您的使用者和服務。傳統軟體測試流程背後的想法，是在程式碼升級到生產責任之前，徹底審查程式碼並檢查已知的弱點。
這種觀點有其優點，但實際情況往往不如表面上那麼清楚。組織在預備環境中執行的測試，通常無法很好地近似程式碼在生產環境中將會遇到的情況。複製環境，包括基礎架構和工作負載，並非易事，而且往往會與實際生產系統失去同步。
這樣做的結果是，您在預備環境中測試的內容，可能實際上不適用於您的程式碼在發布後的效能。此外，無論成功與否，嘗試複製環境都需要大量的人力、時間和基礎架構。
對即時系統的影響
另一個密切相關的擔憂是，新的變更和測試過程本身可能會對生產環境產生影響。系統穩定性是大多數組織的首要之務，因為它可能會影響服務的可用性和可用性，並損害使用者信任。
雖然部署到生產環境的任何程式碼確實有可能影響營運，但有些方法可以將潛在影響降到最低。實施控制措施以限制新程式碼接收的流量、設定主動備用基礎架構，以及實施基於監控的擴展，都是使此過程更安全的方法。這些緩解措施的優點在於，這些投資直接提高了您的生產系統對各種系統故障的彈性。
如何在生產環境中測試
生產環境測試實際上是如何運作的？在本節中，我們將討論組織為了在生產環境中可靠地測試程式碼而實施的一些最常見的技術和策略。雖然不一定要採用所有這些想法，但許多方法彼此互補，並且可以整合為更全面的系統的一部分。
實作功能旗標系統
功能旗標是一種程式設計和發布技術，讓功能可以輕鬆地在外部啟用或停用。基本概念是將新功能包裝在條件邏輯中，該邏輯在執行之前會檢查組態變數的值。「旗標」或「切換」變數通常在 Redis 等外部儲存區中設定，組織可以根據需要輕鬆變更值。
功能旗標是生產環境測試中非常有用的工具，因為它們可讓您安全地部署程式碼，而不會影響生產系統的目前邏輯。新的程式碼路徑可以先停用，然後在準備好測試新程式碼時再啟用。許多功能旗標概念的實作都包含比「已啟用」或「已停用」更精細的控制，並提供針對一定百分比的流量啟用、A/B 測試不同邏輯，或僅在特定情況下選取路徑的選項。
透過使用功能旗標，您可以將程式碼以停用狀態部署到生產環境。您可以使用測試套件測試新的程式碼路徑，同時生產流量繼續使用較舊的邏輯。然後，您可以透過逐步增加新程式碼路徑接收的生產流量，以 Canary 發布 的方式逐步發布程式碼，同時監控影響。
使用 CI/CD 在生產基礎架構上部署和測試
對於生產環境測試的一個誤解是，假設測試必須在生產環境中完成。雖然支持者認可在程式碼最終將執行的環境中進行測試的價值，但並非所有測試都需要如此高的保真度，許多快速、重點明確的測試可以自動化並作為部署程式碼的前導步驟執行。
實作此方法最簡單有效的方式是透過經過良好調整的 CI/CD 流程。CI/CD 是持續整合和持續交付或部署的縮寫，是一個在將新程式碼新增至儲存庫時自動測試新程式碼的系統。一旦測試套件成功通過，流程（持續交付）允許開發人員按一下按鈕即可部署變更，而持續部署則自動部署所有成功測試的程式碼。
CI/CD 在生產環境測試的背景之外還有許多好處。對於我們描述的系統，流程充當部署過程的自動化部分，目標是在生產環境中部署和測試。雖然單元測試等簡單測試可以隔離完成，但整合測試等更複雜的階段最好透過將程式碼部署到生產基礎架構並在那裡進行測試來完成。這可讓您的程式碼在最終將執行的基礎架構上，針對它將互動的實際服務以及相同的執行環境進行測試。
CI/CD 流程有助於建立對新變更的信心，並減輕快速將程式碼部署到生產環境的焦慮。結合功能旗標，開發團隊可以相信程式碼的某些方面已經過審查，然後可以控制如何進行更繁重的測試。
設定您的服務以允許暗啟動
暗啟動是一種部署軟體變更並使用真實流量測試它們的方式，而不會產生面向使用者的後果。這個想法是鏡像生產流量，並將重複的請求傳送到您新部署的程式碼，以便您可以確保它既能正確執行，又能處理實際的生產負載。
暗啟動可能相當複雜，因為它需要您在應用程式的多個執行個體上重播現有流量，而不會造成會影響測試合法性的速度減慢。即時複製請求的替代方案是從事件日誌或其他來源回放先前的請求。此策略需要您從初始請求中擷取所有相關的背景資訊。
暗啟動的好處是，它可以讓您了解程式碼的功能，就好像它已經發布給使用者一樣。透過新程式碼執行的流量結果永遠不會顯示給使用者，但它們可以深入了解您的程式碼的行為方式，以及它需要考量的條件類型。一旦您測試了暗啟動版本的應用程式，您就可以相當有信心地了解它在生產環境中的效能，因為它已經面臨過這些壓力。
實作強大的監控和指標收集
除了在部署和發布期間執行的核心測試之外，重要的是要有系統來讓您能夠持續監控程式碼在生產環境中的行為。可以實作各種相關技術來幫助您深入了解服務的長期健康狀況，讓您在新程式碼導致行為轉變時，能夠更快地發現異常情況。
監控和指標追蹤是您可以使用的基本工具，以了解您的服務在不同條件下隨時間推移的效能。新的變更可能會產生在短期內難以發現的副作用，但可能會隨著時間的推移而變得明顯。監控和指標可以幫助將這些行為上的變化與特定版本建立關聯。
生產環境測試如何影響資料庫？
生產環境測試最複雜的面向之一，是找出有效的方法來執行與資料庫互動的測試。雖然可以讓您的新程式碼從不同的資料來源讀取和寫入，但這再次引入了針對不良複製環境進行測試的可能性。
更好但更難實現的選擇是使用您的生產資料庫進行測試。這可能很難實作，尤其是當您的資料庫綱要和工具未從一開始就針對這種可能性進行設定時，但它可以為了解您的程式碼在發布後的行為提供最佳機會。
允許您的新程式碼從生產資料庫讀取資料相當簡單。只要測試不會導致大量的讀取競爭，它就不應顯著影響資料庫的生產責任，並且對您的生產資料沒有危險。
然而，測試您的程式碼如何執行寫入操作有點棘手。最直接的測試方法是在生產資料庫中建立專用的測試使用者，以便您的新程式碼可以在資料上運作，而不會觸及真實的使用者資料。這仍然可能是一個相當可怕的主張，因為測試操作將與來自您現有程式碼的真實資料一起執行。
結論
生產環境測試可能難以實作，並且可能需要對現有專案進行許多變更。然而，採用一個系統的好處是，您可以在重要的環境中測試程式碼的真實行為，這點再怎麼強調也不為過。測試旨在識別錯誤並建立對軟體的信心，這兩個目標在非代表性環境中都很難完全實現。
透過了解這種方法所涉及的挑戰，您可以評估它與您組織的工作風格有多契合。生產環境測試是一種權衡取捨的練習，您的成功可能很大程度上取決於您願意且能夠投入多少精力到這個過程中。雖然不一定是容易的調整，但從長遠來看，它的優勢可以為您帶來良好的服務。
Prisma Data Platform 可以協助簡化在生產環境中存取資料庫的流程。如果您使用 Prisma Client 來管理資料庫連線，Prisma Data Platform 或許可以協助您更輕鬆地管理生產工作負載。
