8月11日，GitHub 将 Codespaces 提供给 github.com 上的团队和企业云计划。Codespaces 为软件团队提供了一个更快、更具协作性的云端开发环境。
GitHub.com 代码库已有近 14 年的历史。当 GitHub.com 的第一段代码提交推送时，Rails 才诞生两年。AWS 就是其中之一。Azure 和 GCP 尚不存在。这在 COBOL 时代可能不会很长，但在互联网时代却相当多。
在这 14 年中，支持 GitHub.com 的核心存储库已经收到了超过一百万次提交。这些提交中的绝大多数来自在 macOS 上构建和测试的开发人员。
经典提交消息
但是GitHub的开发平台正在不断发展。在过去的几个月里，平台将 macOS 模型抛在脑后，转而使用 Codespaces 进行 GitHub.com 的大部分开发。这是我们日常开发流程的根本转变。因此，Codespaces 产品更强大，为 GitHub.com 的未来发展做好了准备。
现状
多年来，GitHub 投入了大量时间和精力来使本地开发工作开箱即用。一段时间以来，团队的“脚本到规则”方法为工程师提供了一个熟悉的界面——新成员可以克隆github/github、运行设置和引导脚本，并在半天的时间内运行 GitHub.com 的本地实例. 在大多数情况下，一切都奏效了，如果没有奏效，我们的引导脚本会打开一个 GitHub 问题，将新成员与内部支持联系起来。#frictionSlack 频道由乐于助人的热心肠工程师组成，几乎可以调试任何系统配置。
使用这个命令在本地（最终）运行 GitHub.com！
然而，尽管团队做出了种种努力，当地的发展仍然很脆弱。任何看似无害的更改都可能使本地环境变得无用，更糟糕的是，需要数小时的宝贵开发时间来恢复。未知的损坏是如此普遍和灾难性，以至于团队为GitHub的引导脚本编写了一个选项：--nuke-from-orbit. 调用时，脚本会尽可能多地删除，以尝试将本地环境恢复到已知的良好状态。
当然，这是一个经典的故事，软件工程专业的任何人都会立即指出。地方发展环境脆弱。即使在完美运行的情况下，单一上下文、定制的本地开发环境也越来越与我们现在运营的即时启动、随时随地访问的世界格格不入。
在跨多个项目的多个分支上进行协作是痛苦的。当分支引入新的依赖项、发布架构更改或从不同的 SHA 分支时，团队经常盯着自己的引导程序45 分钟。鉴于我们的代码库更改的速度如此之快（我们每天部署数百个更改），这是工程摩擦的常见来源。
GitHub团队并不是唯一注意到的人——在构建 Codespaces 时，团队与几个一流的工程组织合作，这些组织构建了类似 Codespaces 的平台来解决这些相同类型的问题。在任何重大规模上，消除这种类型的生产力损失都会很快成为一个非常明显的生产力机会。
这条单条日志消息会让任何 GitHub 工程师出一身冷汗
发展基础设施
在基础设施领域，行业最佳实践继续将服务器定位为商品。这个想法是，没有一个服务器是独一无二的、不可或缺的或不可替代的。任何作品都可以被取出并替换为类似的作品而无需大张旗鼓。如果服务器出现故障，那没关系！把它拆下来换另一个。
然而，我们当地的开发环境各不相同，都有自己的特殊癖好。因此，他们需要近乎持续的警惕来维持。下一个git pull或bootstrap可能会迅速降低您的环境，当您更愿意构建软件时，需要将昂贵的上下文转移到恢复工作。没有温暖的笔记本电脑待命的约定。
但是，将开发环境视为我们自己的环境有很多话要说——它们是我们度过大部分时间的环境！我们调整我们的工作台以提高效率。
借助 Codespaces，我们看到了一个机会，可以像对待基础设施一样对待我们的开发环境——一种我们可以搅动的商品——但仍然保持管理我们工作台的能力。Visual Studio Code 扩展、设置同步和点文件存储库将我们的环境带到我们的计算中。在这种情况下，损坏的工作台只是一个小小的不便——现在我们可以在已知的良好状态下提供一个新的代码空间并重新开始工作。
采用 Codespaces
迁移到 Codespaces 解决了我们现有开发人员环境中的缺点，激励我们进一步推动产品，并为改善我们的整体开发体验提供了杠杆作用。
虽然我们的迁移故事有一个美好的结局，但我们过渡的第一阶段是……具有挑战性。GitHub.com 存储库在磁盘上几乎有 13 GB；简单地克隆存储库需要 20 分钟。结合依赖设置，引导一个 GitHub.com 代码空间需要 45 分钟以上的时间。一旦我们有一个仓库成功地安装到码域，应用程序将无法运行。
那些 14 年来在我们的引导过程中以 macOS 为中心的假设将不得不被撤销。
克服这些挑战带来了 GitHub 的精华。来自整个公司的贡献者帮助我们重新审视过去的决定，质疑长期存在的假设，并在源代码级别工作以将 GitHub 开发与 macOS 分离。最后，我们可以（虽然速度很慢）在 Linux 主机上提供可用的 GitHub.com Codespaces，从 Visual Studio Code 连接，并交付一些工作。现在我们必须弄清楚如何让这东西嗡嗡作响。
45分钟到5分钟
我们使用 Codespaces 的目标是采用一种模型，在该模型中，为手头的任务按需提供开发环境（分支和代码空间之间的映射大致为 1:1。）为了支持基于任务的工作流，我们需要尽可能接近即时- 尽可能。45 分钟不会满足我们基于任务的栏，但我们可以看到唾手可得的果实，成熟的潜在优化。
首先：改变 Codespaces 克隆 github/github 的方式。Codespaces 现在将执行浅层克隆，而不是在配置时执行完整克隆，然后在使用最近的提交创建 Codespaces 后，在后台执行非浅层存储库历史记录。这样做将克隆时间从 20 分钟缩短到 90 秒。
我们的下一个机会：缓存支持 GitHub.com 的软件和服务网络，包括传统的基于 Gemfile 的依赖项以及用 C、Go 和自定义构建的 Ruby 编写的服务。解决方案是一个 GitHub Action，它将每晚运行，克隆存储库，引导依赖项，并构建和推送结果的 Docker 映像。然后将发布的图像用作 github/github 的 devcontainer 中的基本图像——Codespaces 环境的配置即代码。我们的代码空间现在将在 95%+ 引导时创建。
这两项更改以及少量应用程序和服务级别优化将 GitHub.com Codespaces创建时间从 45 分钟缩短到 5 分钟。但是五分钟距离“即开即用”还有相当大的距离。众所周知的研究表明，人们在失去流动之前可以维持大约10 秒的等待时间。因此，虽然我们取得了巨大的进步，但我们还有很长的路要走。
5 分钟到 10 秒
虽然五分钟代表了显着的改进，但这些变化涉及权衡并暗示了更普遍的产品需求。
我们的浅层克隆方法——对于快速启动到 Codespaces 很有用——仍然需要我们在某个时候支付完整克隆的成本。具有分散注意力的副作用的非浅层创建后生成的负载。任何大型、复杂的项目都会面临类似的问题，在此期间，克隆和引导会导致对可用资源的争用。
如果我们可以提前克隆和引导存储库，以便在工程师要求 Codespaces 时我们已经完成了大部分工作，该怎么办？
进入预构建：代码空间池，完全克隆和引导，等待与想要开始工作的开发人员联系。我们在预构建中所做的工程投资已经多次获得回报：我们现在可以创建可靠的、预配置的代码空间，并在 10 秒内为 GitHub.com 开发做好准备。
与安装 Slack 相比，新员工可以在更短的时间内从零开始进入正常运行的开发环境。工程师可以在没有开销的情况下为并行工作流分离新的 Codespaces。当环境崩溃时——可能是太落后了，或者测试数据破坏了某些东西——我们的工程师可以快速创建一个新环境并继续他们的一天。
增加杠杆
切换到 Codespaces 为我们解决了一些非常现实的问题：它消除了本地开发环境的脆弱性和单轨模型，但也为我们提供了一个强大的新杠杆点来改善 GitHub 的开发人员体验。
我们现在有一个楔子来执行我们在本地环境中从未考虑过的额外设置和优化工作，这些优化的成本（时间和耐心）太高了。例如，通过预构建，我们现在准备我们的语言服务器缓存和 gem 文档，运行待处理的数据库迁移，并启用 GitHub.com 和 GitHub Enterprise 开发模式——一项通常需要通过引导和设置进行另一个循环的任务。
使用 Codespaces，我们可以通过一次配置更改来升级每个工程师的机器规格。在 Codespaces 迁移的早期阶段，我们使用了 8 核、16 GB RAM 的 VM。这些机器已经足够了，但 GitHub.com 运行着一个由不同服务组成的网络，并且很乐意消耗我们愿意提供的每个内核和 RAM 的每一部分。所以我们转向了 32 核、64 GB RAM 的虚拟机。通过改变一行配置，我们升级了每个工程师的机器。
即时升级——出货配置，绕过全球供应链瓶颈
Codespaces 也开始从我们内部的“审查实验室”平台窃取业务——一个类似于生产的环境，我们可以在其中与内部合作者预览更改。在 Codespaces 之前，GitHub 工程师需要提交并部署到审查实验室实例（通常需要同行审查）才能与同事共享他们的工作。摩擦。现在我们 ctrl+click，抓取预览 URL，并将其发送给同事。没有提交、没有推送、没有审查、没有部署——只是在我的 Codespaces 上实时查看端口 80。
命令行
Visual Studio Code 很棒。它是 GitHub.com 工程师用来与 Codespaces 交互的主要工具。但是要求我们的 Vim 和 Emacs 用户使用图形编辑器就没有那么好了。如果 Codespaces 是我们的未来，我们就必须带上所有人。
令人高兴的是，我们可以通过对我们的预构建镜像进行简单更新来支持基于 shell 的同事，该镜像sshd使用我们的 GitHub公钥进行初始化，打开端口 22，并将端口转发出 Codespaces。
从那里，GitHub 工程师可以运行 Vim、Emacs 或 ed，如果他们愿意的话。
这工作得非常好！而且，就像 Docker 图像缓存如何导致预构建一样，下一步显然是采取我们为 GitHub.com 代码空间所做的工作，并使其成为每个代码空间的一流体验。
接待
改变是困难的，在开发环境方面更是如此。值得庆幸的是，GitHub 工程师充满好奇心和善良——并且很快成为 Codespaces 的超级粉丝。
我昨天使用了 Codespaces，而我的开发环境有点破损，在我的开发环境构建完成之前我完成了代码空间的全部功能，哈哈
~@lindseyb
我的朋友们，我在这里告诉你，在这开始之前我是一个 Codespaces 怀疑论者，现在我不是。这就是方法。
~@iolsen
这周我在 Rails 部分的工作中确实比我以前认为的更有效率。一切都如此快速和可靠。
~@jclem 无论是
谁致力于启动和运行 Codespaces，你让我 度过 了一个很棒的第一周！
~@bestra
我郑重发誓，我的 CPU 将不再需要从源代码编译 ruby。
~@latentflip
Codespaces 现在是 GitHub.com 的默认开发环境。#friction我们之前提到的那个Slack 频道可以帮助调试本地开发环境问题？我们正计划将其存档。
我们每天都在 GitHub 上招募更多的服务和更多的工程师，并且我们正在发现关于 Codespaces 可以在此过程中产生的价值的新故事。但在每个故事的核心，您都会发现一个与每位工程师产生共鸣的一致主题：我找到了更好的工具，现在我的工作效率更高，而且我不会回头。
