新智元报道

来源：GitHub

编辑：小匀 Priscilla

【新智元导读】近日，GitHub宣布转移到去年5月就推出的Codespaces，现在，基于浏览器的编码环境Codespaces配置了32核、64GB RAM的VM，提前克隆和引导存储库，只需要10秒时间就能够和团队共享开发环境。

‍

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，给每位工程师的配置都升了级。

参考资料：

https://github.blog/2021-08-11-githubs-engineering-team-moved-codespaces/

https://github.com/features/codespaces

10秒！GitHub工程团队转移到Codespaces，开发环境「即开即用」

新智元报道

【新智元导读】近日，GitHub宣布转移到去年5月就推出的Codespaces，现在，基于浏览器的编码环境Codespaces配置了32核、64GB RAM的VM，提前克隆和引导存储库，只需要10秒时间就能够和团队共享开发环境。

不行就换！