將來，開發人員應該如何處理生產應用程序呢？是應該將本地的生產環境復制到云，還是應該直接在云環境中編寫和運行所有代碼，或者采用介于二者之間的某種方式？
原文鏈接：https://www.signadot.com/blog/large-engineering-teams-testing-on-k8s/
未經允許，禁止轉載！
(相關資料圖)
作者?|?Nica Mellifera? 譯者?| 彎月?
責編 |?王子彧?
出品 | CSDN（ID：CSDNnews）
在過去的幾年里，我們看到很多開發團隊從純粹的本地開發轉向基于云的開發環境。目標是提高開發速度，并控制無法完美復制環境的問題。
在本文中，我們來看看一些企業團隊的解決方案。
在談論開發人員在哪里編寫新代碼時，我們經常提及他們“測試”代碼。這里的“測試”指的是自動化單元測試或端到端測試之前的一個階段，開發人員需要在這個階段研究如何讓代碼與其他資源交互。在測試驅動開發中，這兩個階段可能沒有明顯的區分。在本文中，為了簡潔起見，我們將統一使用“測試”，盡管這個詞本身還包括單獨的一個部署后期階段。
在嘗試與四個不同的企業工程團隊交流后，我發現他們的故事有很多相似之處，所以在此我將他們合并成一個故事。值得注意的是，不僅他們的最終結論非常相似，而且每個團隊在確定基于云的開發環境之前都嘗試了類似的解決方案。
我研究的案例有 Lyft、Reddit、Doordash、Eventbrite 和 Prezi。雖然并非所有團隊最終都選擇使用共享的 Kubernetes 集群，但他們都試圖用類似的方法解決類似的問題，而且都面臨著共同的困難。
在考慮改變開發人員的環境時，我們要考慮的一個關鍵問題是：在開發陷入停滯之前，如何確定投入精力對開發工作流程進行重大改革是否值得？
為此，Eventbrite 團隊在一篇文章中討論了這個決策，標題是：“為什么我們的開發環境運行了一個700個節點的K8s集群？”首當其沖必須考慮的不利因素是：通過共享集群來測試代碼時，工具和集群的開發時間以及維護成本都會增加。
關于在共享 K8s 集群上進行測試，Eventbrite 提到了如下好處：
你是否曾聽開發人員說：“在我本地運行測試時完全沒問題”。在云中運行測試可以提高一致性。事實證明，在探究測試失敗的原因或解決難以重現的問題時，共享開發人員環境能給予極大的幫助。
這是在共享集群上進行測試的核心優勢：更早地發現未知的未知數，并永久消除可怕的一個常見問題：“在我機器上沒問題。”
為了方便開發人員搭建環境，Prezi 等團隊提供了服務安裝、測試以及運行等方面的hook腳本。他們的工具還可以管理服務間通信。但是，由于每位開發者機器的獨特性，hook腳本經常會因為依賴沖突而運行失敗。工程師們花了很多時間來解決這些問題，但在幾個月后重新訪問服務時還是會遇到新的問題。
這種不一致的問題是大型開發團隊沒有同步所有依賴項的必然結果。通常這種不一致在經過長時間的調試后才會顯現出來。
當談論使用容器化工具共享開發環境時，大多數人都會想到Docker。通過容器化所有依賴項并使用 Docker Compose 進行編排，就可以強制開發人員每天同步依賴項。與第一階段相比，這種方法的巨大優勢在于，無需等到失敗才意識到你的環境需要更新。
最大的缺點是，很快你就會發現自己的 macbook 燙手。
每天下載新的容器并重新構建，只為了嘗試一些開發上的小改動，這會極大地影響開發人員的速度。
Docker Compose 的問題在于，它的成本通常是隱藏的，你的筆記本電腦由于運行復雜的工作負載而停滯，因此而造成的時間浪費都無法明確地記入損失。也許每個小時它都會時竊取 10 分鐘。但這不會成為阻止我們在一個月內發布新功能的障礙，結果導致你必須承擔所有壓力，在截止日期之前完成工作。
為了解決本地機器資源有限的問題，我們可以在云中提供虛擬機， 并在其中運行 docker compose。然而，當服務和相關數據庫等的數量超過 15~20 時，這類系統將變得難以管理。
對于 Reddit 團隊，此問題已被確定為已知限制。他們開發了一個自定義工具來最大程度地減少重建和重新下載，以盡量減少每天的啟動時間，并遷移到 kubernetes 集群以共享開發人員進行試驗時所需的大部分資源。他們為此開發了一個名為Tilt的工具進行管理。如果你的團隊有足夠的資源，不僅可以改變開發環境流程，還可以維護內部工具，那就可以考慮采用這種方式大幅縮短每天早上的構建時間。
在 Kubernetes 之上構建遠程環境，這樣開發人員的代碼和依賴項由開發者體驗團隊集中管理，而開發人員的電腦上只需運行一個輕量級命令行工具和幾個庫。
Eventbrite采用的方式與之類似，他們使用了一個名為 yak 的自定義工具來處理開發人員代碼和共享集群之間的交互。yak 還有一個巨大的好處是可以方便開發人員體驗Kubernetes：
這種“輕量級”的交互可以為團隊帶來舒適感，逐步過渡到開發運維。
與共享集群的交互有兩種模式：有些人希望與其他團隊的工作狀態完美同步；而有些人則希望能夠根據自己的設計進行修改。
圖片源自 Reddit Eng 博客，展示了大多數資源的共享方式，而且不會受開發人員實驗的影響。
在 Prezi，開發人員可以自由地在自己的沙箱（Kubernetes 命名空間）中進行試驗，而且可以通過兩種不同的模式運行服務：
●依賴模式：在這種情況下，工具需要提供一組特定的服務，并使用 Helm 和 Helmfile 簡單地部署依賴項的預構建和預優化容器。
●開發模式：這種模式適合正在積極開發的服務。我們使用 Skaffold 構建圖像并同步更改，以便開發人員快速查看修改結果并獲得反饋。
一般而言，你需要設置“待測”服務和剩余的“穩定依賴項”。依賴關系可以按需啟動，就像基于命名空間的方法一樣；或者依賴關系始終存在并通過 CI/CD 工作流不斷更新的共享層來滿足依賴關系，就像請求路由一樣。
以上所有這些案例都涉及內部開發人員體驗團隊維護的工具。這種開發者體驗的成本不容小覷，而且我們也不得不思考這樣一個問題：“為什么沒有適用于這種模型的 SaaS 解決方案？”
Signadot 就是這類的一款 SaaS 工具，可以幫助你共享 Kubernetes 集群并僅在你關心的服務上進行實驗。
兩名開發人員可以同時使用共享的開發集群。環境不需要模擬，而且運營團隊只需維護一個開發集群。
Signadot 絕不是通過開源工具共享開發集群的唯一方式，但它可以處理一些困難的邊緣情況，例如服務之間的請求路由，從而降低了多個開發人員共享一個開發集群的難度。
推薦閱讀：
?小米辟謠武漢總部35歲以上員工只保留10%；豐田致歉！200萬車主車輛數據遭泄露；jQuery 3.7.0 發布|極客頭條
?突發！沉痛悼念技術大牛左耳朵耗子（陳皓）
?突發！OPPO 關停“造芯”業務 ZEKU：近 3000 名員工“原地失業”，賠償 N+3
關鍵詞：
營業執照公示信息