GitHub 的工程团队已转移到 Codespaces

GitHub.com 代码库已有近 14 年的历史。当 GitHub.com 的第一个提交被推送时，Rails 才诞生两年。AWS 就是其中之一。Azure 和 GCP 尚不存在。这在 COBOL 时代可能不会很长，但在互联网时代却相当多。

在这 14 年中，支持 GitHub.com (github/github) 的核心存储库已经收到了超过一百万次提交。这些提交中的绝大多数来自在 macOS 上构建和测试的开发人员

但是我们的开发平台正在不断发展。在过去的几个月里，我们将 macOS 模型抛在脑后，转而使用 Codespaces 进行 GitHub.com 的大部分开发。这是我们日常开发流程的根本转变。因此，Codespaces 产品更强大，我们为 GitHub.com 的未来发展做好了准备

现状

多年来，我们投入了大量时间和精力，使本地开发工作开箱即用。一段时间以来，我们的“脚本到规则”方法为工程师提供了一个熟悉的界面——新员工可以克隆github/github、运行设置和引导脚本，并在半天的时间内运行 GitHub.com 的本地实例. 在大多数情况下，一切都奏效了，如果没有奏效，我们的引导脚本会打开一个 GitHub 问题，将新员工与内部支持联系起来。我们的#frictionSlack 频道由乐于助人的好工程师组成，几乎可以调试任何系统配置

然而，尽管我们做出了种种努力，当地的发展仍然很脆弱。任何看似无害的更改都可能使本地环境变得无用，更糟糕的是，需要数小时的宝贵开发时间来恢复。神秘的损坏是如此普遍和灾难性，以至于我们为我们的引导脚本编写了一个选项：--nuke-from-orbit. 调用时，脚本会尽可能多地删除，以尝试将本地环境恢复到已知的良好状态。

当然，这是一个经典的故事，软件工程专业的任何人都会立即认出。地方发展环境脆弱。即使在完美运行的情况下，单一上下文、定制的本地开发环境也越来越与我们现在运营的即时启动、随时随地访问的世界格格不入。

在跨多个项目的多个分支上进行协作是痛苦的。当分支引入新的依赖项、发布架构更改或从不同的 SHA 分支时，我们经常发现自己盯着 45 分钟的引导程序。鉴于我们的代码库更改的速度如此之快（我们每天部署数百个更改），这是工程摩擦的常见来源。

我们并不是唯一注意到的人——在构建 Codespaces 时，我们与几个一流的工程组织合作，这些组织构建了类似 Codespaces 的平台来解决这些相同类型的问题。在任何重大规模上，消除这种类型的生产力损失都会很快成为一个非常明显的生产力机会

发展基础设施

在基础设施领域，行业最佳实践继续将服务器定位为商品。这个想法是，没有一个服务器是独一无二的、不可或缺的或不可替代的。任何作品都可以被取出并替换为类似的作品而无需大张旗鼓。如果服务器出现故障，那没关系！把它拆下来换另一个。

然而，我们当地的开发环境各不相同，都有自己的特殊癖好。因此，他们需要近乎持续的警惕来维持。下一个git pull或bootstrap可能会迅速降低您的环境，当您更愿意构建软件时，需要将昂贵的上下文转移到恢复工作。没有温暖的笔记本电脑待命的约定。

但是将开发环境视为我们自己的环境有很多话要说——它们是我们度过大部分时间的环境！我们调整和调整我们的工作台以提高生产力，同时也作为我们自己的一种表达。

借助 Codespaces，我们看到了一个机会，可以像对待基础设施一样对待我们的开发环境——一种我们可以搅动的商品——但仍然保持管理我们工作台的能力。Visual Studio Code 扩展、设置同步和点文件存储库将我们的环境带到我们的计算中。在这种情况下，损坏的工作台只是一个小小的不便——现在我们可以在已知的良好状态下提供一个新的代码空间并重新开始工作

采用代码空间

迁移到 Codespaces 解决了我们现有开发人员环境中的缺点，激励我们进一步推动产品，并为改善我们的整体开发体验提供了杠杆作用。

虽然我们的迁移故事有一个美好的结局，但我们过渡的第一阶段是……具有挑战性。GitHub.com 存储库在磁盘上几乎有 13 GB；简单地克隆存储库需要 20 分钟。结合依赖设置，引导一个 GitHub.com 代码空间需要 45 分钟以上的时间。一旦我们有一个仓库成功地安装到码域，应用程序将无法运行。

14 年来，我们的引导过程中以 macOS 为中心的假设将不得不被撤销。

克服这些挑战带来了 GitHub 的精华。来自整个公司的贡献者帮助我们重新审视过去的决定，质疑长期存在的假设，并在源代码级别工作以将 GitHub 开发与 macOS 分离。最后，我们可以（虽然速度很慢）在 Linux 主机上提供可用的 GitHub.com 代码空间，从 Visual Studio Code 连接，并交付一些工作。现在我们必须弄清楚如何让这东西嗡嗡作响。

45分钟到5分钟

我们使用 Codespaces 的目标是采用一种模型，在该模型中，为手头的任务按需提供开发环境（分支和代码空间之间的映射大致为 1:1。）为了支持基于任务的工作流，我们需要尽可能接近即时- 尽可能。45 分钟不会满足我们基于任务的栏，但我们可以看到唾手可得的果实，成熟的潜在优化。

首先：改变 Codespaces 克隆 github/github 的方式。Codespaces 现在将执行浅层克隆，而不是在配置时执行完整克隆，然后在使用最新提交创建代码空间后，在后台执行非浅层存储库历史记录。这样做将克隆时间从 20 分钟缩短到 90 秒。

我们的下一个机会：缓存支持 GitHub.com 的软件和服务网络，包括传统的基于 Gemfile 的依赖项以及用 C、Go 和自定义构建的 Ruby 编写的服务。解决方案是一个 GitHub Action，它将每晚运行，克隆存储库，引导依赖项，并构建和推送结果的 Docker 映像。然后将发布的图像用作 github/github 的 devcontainer 中的基本图像——代码空间环境的配置即代码。我们的代码空间现在将在 95%+ 引导时创建。

这两项更改以及少量应用程序和服务级别优化将 GitHub.com 代码空间创建时间从 45 分钟缩短到 5 分钟。但是五分钟距离“即开即用”还有很长的距离。众所周知的研究表明，人们在失去流动之前可以维持大约10 秒的等待时间。因此，虽然我们取得了巨大的进步，但我们还有很长的路要走

5 分钟到 10 秒

虽然五分钟代表了显着的改进，但这些变化涉及权衡并暗示了更普遍的产品需求。

我们的浅层克隆方法——对于快速启动到代码空间很有用——仍然需要我们在某个时候支付完整克隆的成本。具有分散注意力的副作用的非浅层创建后生成的负载。任何大型、复杂的项目都会面临类似的问题，在此期间，克隆和引导会导致对可用资源的争用。

如果我们可以提前克隆和引导存储库，以便在工程师要求代码空间时我们已经完成了大部分工作，该怎么办？

进入预构建：代码空间池，完全克隆和引导，等待与想要开始工作的开发人员联系。我们在预构建方面的工程投资已经多次回报其价值：我们现在可以创建可靠的、预配置的代码空间，并在 10 秒内为 GitHub.com 开发做好准备。

与安装 Slack 相比，新员工可以在更短的时间内从零开始进入正常运行的开发环境。工程师可以在没有开销的情况下为并行工作流分离新的代码空间。当环境崩溃时——可能是太落后了，或者测试数据破坏了某些东西——我们的工程师可以快速创建一个新环境并继续他们的一天

增加杠杆

切换到 Codespaces 为我们解决了一些非常现实的问题：它消除了本地开发环境的脆弱性和单轨模型，但也为我们提供了一个强大的新杠杆点来改善 GitHub 的开发人员体验。

我们现在有一个楔子来执行我们在本地环境中从未考虑过的额外设置和优化工作，这些优化的成本（时间和耐心）太高了。例如，通过预构建，我们现在准备我们的语言服务器缓存和 gem 文档，运行待处理的数据库迁移，并启用 GitHub.com 和 GitHub Enterprise 开发模式——这项任务通常需要通过引导和设置进行另一个循环。

使用 Codespaces，我们可以通过一次配置更改来升级每个工程师的机器规格。在代码空间迁移的早期阶段，我们使用了 8 核、16 GB RAM 的 VM。这些机器已经足够了，但是 GitHub.com 运行着一个由不同服务组成的网络，并且很乐意消耗我们愿意提供的每个内核和 RAM 的每一部分。所以我们转向了 32 核、64 GB RAM 的虚拟机。通过改变一行配置，我们升级了每个工程师的机器。

Codespaces 也开始从我们内部的“审查实验室”平台窃取业务——一个类似于生产的环境，我们可以在其中与内部合作者预览更改。在 Codespaces 之前，GitHub 工程师需要提交并部署到审查实验室实例（通常需要同行审查）才能与同事共享他们的工作。摩擦。现在我们 ctrl+click，抓取预览 URL，并将其发送给同事。没有提交、没有推送、没有审查、没有部署——只是在我的代码空间上实时查看端口 80

命令行

Visual Studio Code 很棒。它是 GitHub.com 工程师用来与代码空间交互的主要工具。但是要求我们的 Vim 和 Emacs 用户使用图形编辑器就没有那么好了。如果 Codespaces 是我们的未来，我们就必须带上所有人。

令人高兴的是，我们可以通过对我们的预构建镜像进行简单更新来支持基于 shell 的同事，该镜像sshd使用我们的 GitHub公钥进行初始化，打开端口 22，并将端口转发出代码空间。

从那里，GitHub 工程师可以运行 Vim、Emacs 或 ed，如果他们愿意的话。

这工作得非常好！而且，就像 Docker 图像缓存如何导致预构建一样，下一步显然是采取我们为 GitHub.com 代码空间所做的工作，并使其成为每个代码空间的一流体验