云開發平臺如何“提升” DevOps

首先，我來簡單介紹一下什么是云開發環境：它通常運行帶有應用程序的 Linux 操作系統，提供預配置的環境，允許進行編碼、編譯和其他類似于本地環境的操作。從實現的角度來看，這樣的環境類似于遠程運行的進程，通常通過 Docker 或 Podman 等技術進行虛擬化。有關 CDE 的一般概述，請查看 本文。

CDE 技術正在推動當今最快的 DevOps 轉型趨勢，整個云原生開發行業都在將開發環境轉移到線上。這些環境剛剛于 2023 年 8 月成為 Gartner 的新技術類別之一。 值得注意的是，Gartner 預計到 2026 年，60% 以上的云工作負載將使用 CDE 構建和部署。

圖：在線容器可作為 DevOps 三大核心方式的利用

如今，組織可以決定使用自托管平臺來管理這些環境，或者在可用時使用云提供商提供的服務之一。但總體而言，管理這些環境的平臺目前尚處于起步階段，其功能因供應商而異。因此，在如何實施該技術以及最重要的是業務用例涵蓋哪些方面具有很大的靈活性。

我認為，在選擇 CDE 平臺時，企業應該選擇既能提高生產力又能保證數據安全的平臺。使用 安全的云開發環境（即提供數據安全性的環境）可讓組織部署多種機制，例如：防止數據泄露和滲透、自動化 DevSecOps 最佳實踐、生成安全審查等。這種安全性通常是 Citrix 虛擬桌面基礎架構的目標，或者最近使用企業瀏覽器（Island、Talon 或 Chrome Enterprise）的目標。

原因之一是許多公司（包括科技公司）的資產（如源代碼、客戶數據和其他知識產權）都遭受了攻擊。最近備受矚目的源代碼泄露案例包括 Slack 的 GitHub 存儲庫、CircleCI 和 2022 年 12 月的 Okta。最重要的是，我認為安全應該被定位為生產力的助推器，這樣它才能有助于改善開發人員的體驗，而不是成為阻礙。

現有平臺之間的共同點之一是旨在提高代碼開發效率。無論您是否選擇將安全性考慮在內，很明顯 CDE 可以釋放大量生產力，從而有利于 DevOps 工作流程。這就是為什么我在這里重新審視 DevOps 的核心原則并重新思考這些環境如何為它們帶來新的啟示。這些原則也被稱為三種方式，并在Kim、Debois 和 Willis 的《DevOps 手冊》中進行了解釋。

在線環境加速 DevOps 的流程原則

從流程的角度來看，DevOps 是關于實施三個原則（或方式）：即流程、反饋和持續學習原則。我認為，在這種情況下解釋 CDE 的好處是理解它們的一些關鍵影響的好方法。

圖：Kim、Debois 和 Willis 在《DevOps 手冊》中描述了 DevOps 的三種方式，即流程、反饋和持續學習

讓我們從流程原則開始。第一個原則強調工作從開發到測試、部署再到運營和監控的順暢和高效流動。它旨在最大限度地減少瓶頸、優化流程并實現連續和無縫的交付流程。流程通常由沿無窮大符號排列的一系列階段表示。

CDE 是實現流動原則的有效方法，因為它們允許用戶在處理多個項目時擁有完全隔離的工作區設置，從而實現它們之間直接且無影響的上下文切換。

良好的 CDE 平臺為開發人員提供了多種工具來管理和配置他們的 CDE，特別是基于公司政策。例如，開發人員可以自助訪問 CDE，這是一項重要優勢。

CDE 還可以輕松復制以進行測試，并可以根據需要在用戶之間重新分配。它們可以完全模板化，在幾秒鐘內配置到靈活的資源上，并且任何開發人員都可以訪問，無論他們身在何處。在這里，一個好的 CDE 平臺為項目和 IT 經理提供全面的操作，從而實現大規模的 CDE 管理和可觀察性。

圖：CDE 的使用始于 DevOps 的代碼階段，使組織能夠跨階段保持一致的環境。CDE 及其訪問機制分別由圖塊和一系列圖標表示。

顯然，CDE 的在線部署允許集中管理、可觀察性和訪問，從而真正增強了 DevOps 的流動原則。

如今，遠程開發人員的加入已成為大多數組織運營的一部分。CDE 的在線特性非常適合在完全配置的環境中讓開發人員入職，無論他們身在何處。提供對組織資源的訪問權限也是入職的一個重要方面。在這里，CDE 提供了一種以集中方式訪問開發資源的新機會，特別是提供增強的控制和可觀察性的方式。

為了將生產力與靈活性結合起來，一個好的 CDE 平臺必須提供資源訪問權限模型，以允許處理不同類型的開發人員、不同的開發場景（內部、協作等）和不同類型的資源。例如，基于角色和基于屬性的訪問控制 (RBAC/ABAC) 加上對資源進行分類的機制，使組織能夠設置風險控制并確保治理，即使在復雜的工作流程情況下也是如此。這大大增強了設計高效協作開發流程的可能性。

圖：引入多元化的開發人員需要一種機制來根據角色管理對資源的訪問權限。還可以根據用戶位置等屬性動態評估權限。

最后，CDE 和基于 Web 的 IDE 聯合使用的一大優點是，在瘦設備或 BYOD 模式下加入開發人員可以立即加速業務擴展。

如何將即時性帶入 DevOps 的反饋原則

反饋原則涉及在開發和運營流程的不同階段之間建立溝通和協作機制。這包括從各種來源收集反饋，例如最終用戶、監控系統和測試流程。該原則的一個重要方面是它使開發人員之間能夠更好地協作。

DevOps 的第二個原則最好地體現在代碼存儲庫應用程序中實現的Pull Request (PR) 機制。使用 PR，開發人員可以在將分支提交的工作合并到應用程序之前對其進行評論。

CDE 的在線特性使反饋原則更貼近開發人員，即在工作到達代碼存儲庫之前，即在編碼活動的中心。CDE 通常與訪問或監控它的機制（例如 IDE、終端、網絡、編排等）結合使用，從而實現這一優勢。

由于 CDE 是在線運行的進程，因此很容易觀察工作進展情況。這讓人想起觀察網站訪問者的用戶體驗。在我看來，這是最有可能將生產力和安全性置于開發核心的領域。

圖：由于 CDE 可以遠程訪問，因此很容易測量它們的一些屬性，例如正在運行的進程和分配的資源。

例如，可以很容易地實時測量一組 CDE（例如由共同項目的開發人員共享）構建應用程序所需的平均編譯時間（見上圖）。這為項目經理提供了有關生產力的即時和有價值的信息。

還可以輕松查看通過開發人員剪貼板傳遞的信息和 CDE 的網絡流量。利用這些渠道，我們可以向開發人員和管理人員提供反饋。例如，從基礎設施安全角度來看，可以輕松監控潛在的數據泄露并防止知識產權損失。

但通過同樣的渠道，人們還可以尋找潛在的惡意數據滲透。例如，假設您可以檢測到開發人員剪貼板中的憑據，那么詢問開發人員執行此操作的意圖怎么樣？當開發人員即將將從隨機網站收集的源代碼粘貼到您的代碼庫中時，也是有可能的。您想標記它并自動創建安全審查嗎？如何在惡意軟件進入您的代碼庫之前檢測它或系統地標記 AI 生成的代碼怎么樣？

圖：對 CDE 及其支持基礎設施的控制是對輸入數據（如憑證、許可源代碼和潛在惡意軟件）進行語義分析的機會。同樣，它允許設置數據泄漏預防措施。

顯然，CDE 和用于將數據導入其中的基礎設施組件是引入 DevOps 和 DevSecOps 中一批新最佳實踐并重新審視 DevOps 反饋原則的媒介。通過我上面給出的例子，你可以看到基礎設施安全可以與代碼安全原則相聯系！

一個好的 CDE 平臺肯定會提供一系列新穎且富有創意的 DevOps 和 DevSecOps 自動化。此外，還有一個很好的機會來重新審視標準化和公認的指標，例如 DORA 和 SPACE，使它們更接近開發人員在 IDE 中編寫代碼所花費時間最多的活動。

持續學習原則的特寫

現在讓我們用第三個原則，即持續學習原則來結束本次討論。該原則強調在開發和運營團隊中培養持續改進和學習的文化的重要性。它涉及定期收集反饋、分析績效指標以及吸取開發和部署過程每個階段的經驗教訓，以提高效率和創新能力。

網絡平臺的即時性以及它們帶來的觀察業務流程的機會也使組織能夠了解自己。這是增加持續學習潛力的一大福音。

最初，DevOps 對持續學習的期望是圍繞改進運行中的應用程序（即客戶正在使用的應用程序）。但是，當整個開發過程作為云應用程序運行時，組織可以學到很多關于其?自身基于平臺的開發過程的寶貴知識。

本著這一思路，CDE 平臺帶來了全新水平的可觀察性，并允許圍繞多個關鍵領域進行業務優化。我已經討論過組織如何了解其在應用程序交付和安全態勢方面的績效。但他們還可以了解云和物理資產的利用率，以及監控 IT 功能的成本和分配給開發的資源。該平臺還帶來了一個絕佳的機會，可以集中實施生產力和風險控制，同時在分散在不同地理位置的團隊中系統地執行這些控制。實際上，現代 CDE 平臺需要允許同時在多個地區使用多個云。最重要的是，它們能夠統一向組織提供復雜的服務，這使得實施不會妨礙用戶日常任務的治理機制變得容易。

圖：DevOps 的持續學習原則也適用于開發過程本身。CDE 產生了一系列新的流程測量，有利于治理、問責和風險控制。

總之，良好的 CDE 平臺應為組織帶來豐富的指標和功能，以便他們重新控制通常分散、跨硬件和應用程序不統一且有時從安全角度來看模糊的開發過程。這就是為什么在我看來，采用趨勢將有增無減的原因。此外，我們應該看到對 CDE 提供商增強安全控制能力的需求越來越大，同時確保它們最終不會對開發人員的生產力產生任何負面影響。最后，開發 CDE 屬性作為增強 DevOps 三種方式的一種方式，是推動開發社區以有意義的方式進行創新的絕佳框架。