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。