Dogfooding！GitHub.com工程團隊開發環境上Codespaces

隨著GitHub的規模不斷擴增，程式碼庫也越來越龐大，為了讓GitHub新的開發成員快速上手，以及提供更方便的開發環境，GitHub工程團隊從原先以macOS為中心的開發模型，轉而使用Codespaces，並且採用預建置等方法，將啟動開發環境的時間縮減至10秒鐘。另外，GitHub也宣布，開始向Team和Enterprise Cloud方案用戶提供Codespaces，並擴展個人方案用戶的測試規模。

距離GitHub.com第一個程式碼提交已經14年，在這14年間，GitHub.com核心儲存庫已經收到超過一百萬次提交，而這些提交絕大多數，來自在macOS上建置和測試的開發人員，而隨著GitHub開發平臺不斷發展，macOS模型已經不適用。

多年來，GitHub採用一種稱為Scripts-to-rule-them-all的方法，讓新加入開發團隊的成員，可以複製github/github儲存庫、執行設定、載入腳本，並且能夠在半天的時間，就成功於本地執行個體執行GitHub.com，當流程無法順利進行，則腳本會自動幫新進成員連接到內部支援人員，以快速解決問題。

但GitHub提到，儘管他們做出許多努力，但本地端開發環境仍然非常脆弱容易出錯，有時候甚至需要開發者花數小時的時間來恢復開發環境，而且這種情形並不少見，他們甚至特別編寫了一個稱為--nuke-from-orbit的腳本來解決這類問題，該腳本會嘗試刪除設定，盡可能將本地環境恢復成為良好狀態。

另外，GitHub認為，單一上下文且訂製的本地端開發環境，與現在GitHub的營運需求，包含即時啟動、從任何地方存取的哲學格格不入，開發者在跨多個專案的多個分支上協作更是不便，當新分支加入新的相依項目、發布架構更改或是從不同的SHA分支的時候，常需要花費45分鐘以上的等待時間。

在GitHub建構Codespaces時，他們發現不少企業遭遇相同的問題，而這些企業也在組織內建構類似Codespaces的平臺，來解決這類問題，GitHub提到，在大規模的組織中，消除這類型的生產力損失，將會是明顯提升生產力的好方法。

Codespaces是GitHub在2020年發布的新服務，讓用戶可以直接在網頁IDE編輯程式碼，並且使用所有VS Code瀏覽器版本的所有功能，包括配置程式碼和相依項目等功能，其一大優點是可以簡單地切換開發環境。官方提到，將GitHub.com程式碼庫搬到Codespaces，解決了GitHub開發環境現有的缺點。

Codespaces讓開發者依據手上任務，按需獲取開發環境，不過，這也帶來新的問題，基於任務的工作流程，需要接近即時的速度，但因為光是簡單地複製GitHub.com儲存庫13 GB的檔案，就需要20分鐘，再加上相依性配置設定，要完整載入一個GitHub.com程式碼空間，需要花費45分鐘，這個時間無法滿足基於任務的開發環境條件。

因此GitHub進行了一些方法來加速獲取程式碼庫的速度，首先是改變Codespaces複製的方法，讓Codespaces進行淺層複製，不在配置時進行完整複製，僅在最新的程式碼提交，Codespace創建之後，才會在背景進行非淺層複製，這樣可使得一開始複製時間，從20分鐘降為90秒。同時，GitHub每晚還會執行一個GitHub Action，將儲存庫、相依項目和建置等檔案打包成為映像檔，這個映像檔被用作github/github的開發容器，以配置即程式碼的方式建構Codespaces環境。

這兩項改變以及一些應用和服務層級的最佳化，使得GitHub.com程式碼空間的創建時間，從45分鐘縮短至5分鐘。雖然5分鐘已經是很大的進步了，但是GitHub仍不滿足，因此他們又採用預建置方法，在Codespaces池中準備事先啟動的開發環境，等待需要的開發者連接存取，這樣的方法可以讓開發者在10秒內，立即使用到GitHub.com開發環境。

在Codespaces中，GitHub能夠簡單地配置每個開發者所使用的機器規格，一開始使用8核心、16 GB記憶體的虛擬機器，為了符合更多元服務的需求，因此進一步提高機器規格到32核心、64 GB記憶體的虛擬機器，GitHub提到，這個過程只需要更改一行配置，就能夠立刻升級每個工程師的機器。

除了使用VS Code作為主要來操作程式碼空間的工具，原本使用Vim和Emacs的用戶，也能夠使用程式碼空間，GitHub藉由升級預建置映像檔，讓該映像檔使用GitHub公鑰，並且開啟22連接埠，並從埠口轉送程式碼空間，讓不使用圖形介面編輯器的用戶也可以用到Codespaces。