[[417451]]

Github宣布：轉移到 Codespaces。

GitHub通過博客告知開發者們，他們將其擴展到GitHub團隊和企業（云）計劃，開始更廣泛地推出其基于瀏覽器的編碼環境Codespaces。

這家微軟旗下的公司還宣布，內部已經從MacOS模式過渡到Codespaces，后者現在是GitHub的默認開發環境。

GitHub于去年5月首次推出Codespaces，作為具有所有常用GitHub功能的云托管開發環境。

它基本上由微軟的Visual Studio Code提供支持，該代碼自2019年起作為基于Web的編輯器提供，并于去年更名為Visual Studio Codespaces。

9 月，微軟還確認將Visual Studio Codespaces整合到GitHub Codespaces 中。

GitHub的Codespaces最初是在面向個人用戶的「有限公開測試版」中推出的，而現在團隊或企業（不包括自托管）計劃中的所有企業都可以在其 GitHub設置中主動啟用Codespaces，并且他們現在可以在所有私有存儲庫中使用Codespaces。

通過將編碼環境帶到云端，開發人員可以更輕松地加入和協作項目，并以最少的配置開始編碼。

在這14年中，支持GitHub.com (github/github) 的核心存儲庫已經收到了超過一百萬次提交。這些提交中的絕大多數來自在 macOS 上構建和測試的開發人員。

不行就換！

將GitHub遷移到Codespaces能夠解決開發者環境不同的問題。

想法有多理想，實現起來就有多困難。

GitHub.com存儲庫在磁盤上幾乎占了13GB。

只是簡單地克隆一下存儲庫，啪，20分鐘就過去了。

結合依賴設置，bootstrap一下GitHub.com的代碼空間，45分鐘過去了。

一旦將存儲庫成功掛載到代碼空間中，應用程序還不運行了。

14年來，以macOS為中心的設想付之東流。

但堅強的工程團隊又怎么會輕言放棄！

他們開始質疑一直以來的設想，并在源代碼級別工作以將GitHub開發與macOS分離。

最后，雖然速度很慢，但至少可以在Linux主機上提供可用的GitHub.com代碼空間，從Visual Studio Code連接，交付一些工作。

下面來看看團隊是如何實現「閃電般速度」的云端開發環境。

從45min到5min

使用Codespaces的目標是希望能夠為手頭的任務按需提供開發環境，分支和代碼空間之間的映射大致為1:1。

為了支持基于任務的工作流，團隊希望能夠做到「即開即用」。

團隊不滿足于45分鐘，但是這個時間長度還是能讓人看到希望。

首先是要改變Codespaces克隆github/github的方式。

與之前在配置時執行完整克隆不同，現在Codespaces執行的是淺層克隆。

然后在使用最新提交創建代碼空間后，在后臺執行非淺層存儲庫歷史記錄。

這樣克隆時間就能從20分鐘縮短到90秒！

下一個要改進的，是緩存支持GitHub.com的軟件和服務網絡。

包括傳統的基于Gemfile的依賴項以及用C、Go和自定義構建的Ruby編寫的服務。

團隊提出了一個解決方案，那就是讓GitHub Action每天晚上夜深人靜的時候悄悄運行。

當然是為了克隆存儲庫，引導依賴項，還有構建和推送結果的Docker image。

發布的image隨后被用作github/github的
devcontainer-config-as-code中的基礎鏡像，構成Codespaces環境。

在瀏覽器中通過即時重新加載來預覽更改，還能與隊友共享私有和公共端口。

就憑這兩項更改（以及少量應用程序和服務級別優化），就能將GitHub.com代碼空間的創建時間從45分鐘縮短到5分鐘。

不過這屆GitHub工程團隊真的很嚴格。

他們覺得五分鐘，距離「即開即用」的目標還有相當大的距離。

從5min到10s

快速啟動到代碼空間，淺層克隆方法還是很有用的，不過有時還是需要完整克隆。

所以團隊就想，為什么不能提前克隆和引導存儲庫呢？

光想不做是大忌。

進入預構建：代碼空間池，完全克隆和引導，等待開發人員聯系。

最終，現在能夠創建可靠的預配置代碼空間。

而且在10秒內就能準備完畢。

跟以前哼哧哼哧安裝Slack相比，現在新員工可以在更短的時間內，從零開始進入正常運行的開發環境。

要是開發環境崩潰了，比如太落后，或者測試數據產生了破壞，工程師也能夠快速創建一個新環境。

標準化的開發環境

另外，切換到Codespaces還能解決掉一些非常現實的問題。

它消除了本地開發環境的脆弱性和單軌模型，但同時也改善了GitHub開發人員的體驗。

剛開始切換到Codespaces時，用的是8核、16GB RAM的VM。

本來有這些配置已經足夠了，但GitHub運行的網絡由不同服務組成，消耗很大。

所以后來更換成了32核、64GB RAM的VM，給每位工程師的配置都升了級。