什麼是CDE（雲開發環境）？與本地開發環境有何區別？

雲開發環境（CDEs）正在徹底改變軟體開發。

CDEs 將編寫程式碼、執行構建、執行測試和部署應用程式等關鍵開發流程轉移到雲中，為工程師提供了靈活性、效率和簡便性。這讓開發人員能夠更好地協作，更快地釋出更高質量的軟體，而不會讓環境成為障礙。

讓我們來探討一下 CDEs 到底是什麼、有哪些優勢、值得評估的選項、配置第一個雲開發環境的簡單步驟以及長期優化使用的技巧。

什麼是雲開發環境？

雲開發環境是軟體開發團隊協作、構建、測試和部署應用程式的集中平臺。

僅在 2020 年至 2022 年期間，就有相當一部分企業遷移到主要基於雲的開發環境，因此我們認為您有必要了解所有細節，以防您也在考慮遷移。

CDE 將整個開發生命週期整合到一個整合的雲工作區中，使開發人員不再擁有分散的工具鏈，也不再依賴於不同的個人和裝置。整合開發環境（IDE）、執行時、基礎架構配置、依賴關係、協作工具、測試框架和管道等核心元件被捆綁在一起，並可通過雲瀏覽器訪問。與傳統開發環境相比，雲環境託管在雲上，可通過網路瀏覽器或應用程式訪問。所有計算量大的過程，如編譯程式碼、執行自動測試或構建容器，都在雲中進行。開發人員只使用本地裝置作為瘦客戶機訪問雲工作區，從而降低了總體硬體成本。

雲開發平臺還提供預建模板，可快速為特定應用程式堆疊啟動開發環境，或在需要時為高階自定義配置提供更多控制。有了這些，您就可以在各個團隊中擁有一致的環境。

在許多方面，CDEs 代表了軟體開發的下一個發展階段–一個以云為中心的發展階段。它利用了雲端計算的基本功能，同時允許本地環境的可控靈活性。

讓我們進一步瞭解 CDEs 與本地環境的不同之處，以及這種設定的優勢和侷限性。

雲開發與本地開發有何不同？

開發雲應用程式不同於程式碼在開發人員裝置上孤立存在的傳統設定。

在高層次上，雲環境允許工程師在遠端託管的一致工具包上進行實時協作。

這種方法解決了團隊在跨地點和跨裝置配置、訪問和同步開發環境時面臨的許多難題。

雲開發有哪些優勢？

既然您已經瞭解了雲開發環境的基本原理以及它們與傳統設定的區別，那麼讓我們來看看 CDEs 的主要優勢。

提高安全性

通過將開發整合到 AWS 或 Azure 等受監管的雲平臺，您可以最大限度地減少攻擊面。

與丟失或損壞的開發人員膝上型電腦相比，所有敏感憑證、公司 IP 和個人資料都將受到保護。

雲基礎設施還提供加密、訪問控制和合規性框架等安全功能，這些功能對於單個工程師來說，單獨實施的成本過高。

協同工作

本地開發的程式碼在審查之前都處於孤立的分支和分叉中。雲整合開發環境可以實現 Google 文件式的程式碼實時編輯和註釋，因為現在的環境是共享的。

團隊進度從一開始就可以視覺化，根據環境配置的不同，任何有必要訪問許可權的人甚至可以在程式碼編寫過程中看到程式碼。

提高生產力和入職效率

在本地裝置上進行分散式開發的傳統設定中，新開發人員的入職可能既困難又耗時。在開發人員開始工作之前，你需要從頭開始配置新機器。

開發人員還要浪費大量時間，排除與編寫程式碼無關的環境、依賴性和配置問題。2023 年的一項調查顯示，50% 以上的開發人員時間用於維護、配置和操作任務。

然而，CDEs 可以集中處理這些複雜問題，讓開發人員專注於構建產品，而不是與環境作鬥爭。它們通過在一個基於雲的整合開發環境中分配工具來優化工作流程。與模板化的開發人員環境、自動化的基礎架構管理和快速的測試執行相配合，它可以大大提高開發人員的工作效率。

可擴充套件性

在本地執行資源繁重的構建和測試流程會降低機器的執行速度，限制並行化的實現。

然而，使用 CDEs 的軟體團隊無需採購額外的硬體，就能更快地擴充套件。

啟動新的雲開發環境只需幾分鐘，因此可以更快地擴充套件團隊。

例如，如果您臨時需要高運算量來測試重負載下的應用程式效能，您可以增加雲例項的資源，而無需超支。許多雲開發環境會根據系統負載自動擴大或縮小。

避免配置偏移

在本地設定中，開發人員必須在本地機器上手動安裝所有必需的元件，如編輯器、語言包、框架和資料庫。配置這些本地化工具鏈既複雜又耗時。

隨著時間的推移，這些元件還會在開發人員的裝置上變得支離破碎。這就是所謂的配置漂移，通常會導致可怕的 “能在我的機器上執行” 的錯誤。

另一方面，雲開發平臺會在一個集中的位置進行設定和託管。工程師通過網路瀏覽器訪問遠端環境，無需配置本地工具。所有團隊成員在雲中使用相同的完全打包、最新的工具集。

雖然雲開發環境有許多優點，但也有缺點。

使用 CDE 有哪些弊端？

採用任何新技術都會帶來進步和危險。以下是利用 CDE 的幾個潛在弊端：

• 複雜的初始設定：構建 CDE 需要大量的雲端計算和 DevOps 專業知識，以及與 SSO、安全控制、使用者介面、協作工具等眾多服務的複雜整合。如果您不具備所需的資源，那麼在實施 CDE 之前提高技能或僱傭新人可能是個不錯的主意。
• 供應商依賴性：選擇託管 CDE 解決方案往往會導致供應商鎖定。如果需要遷移平臺，可能會遇到困難。
• 陡峭的學習曲線：採用基於雲的工作流程會迫使團隊學習新的概念、實踐和工具。這在開始階段可能會耗費大量時間。
• 依賴連線：當網際網路訪問中斷時，開發人員就會斷開連線。此外，CDE 的響應延遲比本地環境高得多，這會影響使用者體驗。本地環境可避免這些問題。
• 持續開銷：雲基礎設施、強大的 CI/CD 流水線、自動化功能和安全保障–所有這些都有相關的經常性維護開銷，如成本、升級、故障排除等。提供的功能越多，執行負荷就越大。例如，眾所周知，AWS 是非常昂貴的。

如何建立自己的雲開發環境

如果您確信雲開發環境適合您的組織，那麼讓我們快速瞭解一下如何建立自己的 CDE。

第 1 步：選擇 CDE 提供商

有多種雲開發環境可供評估，比如：

• Gitpod – 與 GitHub 程式碼庫整合的基於瀏覽器的 CDE
• AWS Cloud9 – 與 AWS 服務緊密結合的全面管理的雲 IDE
• Microsoft Visual Studio Online – 與 Azure 相連線的雲版 Visual Studio IDE

花時間比較各種選項，如語言支援、協作、安全性、整合、定價和學習資源。註冊試用賬戶，並在可用的地方建立開發環境。儘量尋找有開源社羣支援的解決方案，以免出現問題時陷入困境。

第 2 步：建立雲賬戶

選定平臺後，如果還沒有賬戶，請在相應的雲提供商處建立一個賬戶。例如，Gitpod 依賴於 GitHub，而 AWS Cloud9 等解決方案則需要 AWS 賬戶。

在初始雲賬戶設定過程中，瀏覽儀表板，找到可以訪問平臺提供的各種計算、儲存、網路和其他服務的位置。在試用過程中，在這方面花點時間將有助於你瞭解在全公司範圍內採用它的難易程度。

第 3 步：建立第一個虛擬機器

建立賬戶後，在所選 CDE 平臺中設定初始開發環境或 “dev box”。大多數 CDE 提供預配置模板，可在幾分鐘內啟動虛擬機器或開發容器，並提供程式碼編輯器和終端等所有基本工具。

如果存在模板配置，可從 CDE 供應商為 Node.js、Python 或 Java 等流行語言提供的官方映像開始。這些準備好的環境雖然必不可少，但可以讓初次使用的使用者快速體驗雲開發。然後，您可以將其作為基礎映象來構建自定義環境。

第 4 步：配置安全性和聯網

在允許團隊廣泛使用之前，請考慮圍繞新的 CDE 部署定義安全防護欄和網路規則。考慮：

• 要求多因素身份驗證才能訪問環境
• 限制建立/刪除雲資源的許可權
• 啟用敏感工件的加密儲存
• 在私有云網路中隔離團隊開發
• 記錄使用者操作和基礎設施變更

在後期階段，您可能需要在 CDE 管道中實施機密管理、基礎架構安全掃描等，以提高共享環境的安全性。

第 5 步：安裝您最喜歡的開發工具

現在，基本環境和環境變數已經設定完畢，並確保了團隊使用的安全性，可以通過安裝其他開發工具來進一步自定義環境和環境變數。對於建立開發環境，下一步顯然是安裝編碼編輯器、編譯器、資料庫、網路伺服器和其他軟體，以建立一個程式設計工具箱。

所有 CDE 都允許你自定義伺服器上的工具鏈。在 Linux 上使用本地軟體包管理器安裝所有工具。對於 Windows，可直接從網際網路下載安裝程式到雲例項。

在整個過程中，切記記錄所有步驟、執行的命令和配置的工具，以便將來輕鬆重現環境。您希望這些文件成為 CDE 的唯一真相來源 (SSOT)。

第 6 步：構建、測試和部署

最後，開始測試雲開發環境，利用雲驅動的工作流來編碼、構建、測試和部署應用程式。瞭解如何跨機器快照持久狀態，以保持連續性或重現問題。

通過配置自動版本控制以及在程式碼提交時觸發自動構建和測試，提高團隊的工作效率。

隨著雲開發的成熟，應定期完善和優化環境，在標準化和定製化之間取得平衡。CDE 應成為開發人員的自然選擇，而不是被迫使用的限制性環境。

使用雲開發環境的技巧

除了初始設定外，以下是長期使用雲開發環境獲得額外優勢的五個技巧。

連線其他雲服務

CDE 平臺可與同一供應商管理的互補雲服務緊密整合。例如，AWS Cloud9 keypair 身份驗證提高了亞馬遜 EC2 基礎設施的安全性。

探索無伺服器資料庫、儲存、訊息傳遞和 API 等雲服務簡化構建的方式。檢視相關架構圖，詳細瞭解產品如何相互交叉，然後有選擇性地將它們納入其中。有疑問時，調查開發團隊成員，詢問他們希望新增或刪除哪些工具鏈。

擁抱自動化

想方設法儘可能多地應用基礎設施即程式碼技術和 CDE 配置。使用 Dockerfiles、Terraform、Ansible 或其他方法將環境模板化，並簡化開發人員的配置，以便他們在安全防護範圍內工作。

越早實現環境配置自動化，就能越快地部署全新的開發環境並建立易於移植的環境。

關注使用情況

雲端計算的可變成本模式可能會導致未優化開發帶來的貼紙衝擊。利用 AWS Cost Explorer 等工具持續監控環境使用情況，識別閒置資源、臃腫許可權或區域配置錯誤造成的浪費。

將雲成本可見性整合到現有儀表板中，重點關注環境擴充套件時的支出異常。此外，還要制定嚴格的預算，在不影響工作效率的情況下為每月的開發基礎設施支出設定上限。

只遷移所需的資料

在將長期專案過渡到 CDE 時，要評估快取、檔案庫或本地資料庫是否需要雲遷移。看看是否可以通過符號連結到原來的內部部署位置來滿足開發需求。

資料傳輸的成本可能會很高，這往往也是企業向雲提供商支付高昂月費的原因。因此，請確保您挑選的是最關鍵的資料。

遵循共同責任模式

所有主要雲提供商都遵守 “責任共擔模式“，該模式規定了客戶和供應商之間的安全控制所有權。花點時間瞭解負責確保各環境層安全的實體的界限。

例如，亞馬遜負責保護較低層次的雲基礎設施，但客戶必須適當配置身份、許可權、加密和網路安全層。分析並堅持自己的責任分擔協議。

小結

您已經使用新的 CDE 創造了下一個大事件。恭喜你！但現在您需要一個地方來託管您的網路應用程式，以便真實使用者可以在開發環境之外訪問它。設定和管理託管伺服器是一件麻煩事，尤其是在大規模部署時。