Github宣布：转移到Codespaces。GitHub通过博客通知开发人员，他们正在扩展GitHubTeams和企业（云）计划，开始更广泛地推出基于浏览器的编码环境Codespaces。这家微软旗下的公司还宣布，它已经在内部从MacOS模型过渡到Codespaces，后者现在是GitHub的默认开发环境。GitHub于去年5月首次推出Codespaces，作为具有所有常用GitHub功能的云托管开发环境。它基本上由Microsoft的VisualStudioCode提供支持，该代码自2019年以来一直作为基于Web的编辑器提供，并于去年更名为VisualStudioCodespaces。9月，微软还确认将VisualStudioCodespaces整合到GitHubCodespaces中。CodespacesforGitHub最初是针对个人用户推出的“有限公开测试版”，现在Teams或Enterprise（不包括自托管）计划中的所有企业都可以在其GitHub设置中主动启用Codespaces，并且现在可以使用Codespaces在所有私有存储库中。通过将编码环境带到云端，开发人员可以更轻松地加入和协作项目，并以最少的配置开始编码。在这14年中，支持GitHub.com(github/github)的核心存储库已收到超过一百万次提交。这些提交中的绝大多数来自在macOS上构建和测试的开发人员。如果没有，请更改它！将GitHub迁移到Codespaces可以解决不同开发者环境的问题。想法有多理想，实现起来就有多困难。GitHub.com存储库占用了将近13GB的磁盘空间。只是简单地克隆了存储库，砰的一声，20分钟过去了。结合依赖设置，bootstrapGitHub.com的代码空间，45分钟过去了。一旦存储库成功安装到代码空间，应用程序还没有运行。14年来，以macOS为中心的愿景付诸东流。但是强大的工程团队又岂会轻易放弃！他们开始质疑假设并在源代码级别开展工作，以将GitHub开发与macOS分开。最后，虽然速度很慢，但至少在Linux主机上有一个可用的GitHub.com代码空间，从VisualStudioCode连接，交付了一些工作。让我们来看看团队是如何实现“闪电般速度”的云开发环境的。使用45min到5min的Codespaces的目的是为手头的任务提供一个按需的开发环境，branchs和codespaces的映射大致是1:1。为了支持基于任务的工作流程，该团队希望能够“开箱即用”。球队对45分钟并不满意，但这个时间长度还是可以让人看到希望的。首先是改变Codespaces克隆github/github的方式。Codespaces现在执行浅克隆，而不是在配置时执行完整克隆。在使用最新提交创建代码空间之后，然后在后台执行非浅存储库历史记录。这将克隆时间从20分钟缩短到90秒！接下来要改进的是缓存为GitHub.com提供支持的软件和服务网络。包括传统的基于Gemfile的依赖项以及用C、Go和自定义构建的Ruby编写的服务。团队想出了一个解决方案，就是让GitHubActions在每晚夜深人静的时候悄悄运行。当然是克隆存储库、引导依赖项、构建和推送生成的Docker映像。然后将发布的镜像在github/github的devcontainer-config-as-code中作为基础镜像，构成Codespaces环境。通过即时重新加载在浏览器中预览更改，并与队友共享私有和公共端口。仅这两项更改（连同一些应用程序和服务级别优化）将创建GitHub.com代码空间的时间从45分钟缩短到5分钟。但是这个GitHub工程团队真的很严格。他们觉得五分钟距离“即时使用”的目标还有很长的路要走。从5min到10s快速启动到代码空间，shallowclone的方法还是很有用的，但是有时候还是需要fullclone。所以团队想，为什么不提前克隆和引导存储库呢？想而不做是大忌。访问预构建：代码空间池，完全克隆和引导，等待开发人员联系。最后，现在可以创建可靠的预配置代码空间。不到10秒即可准备就绪。新员工只需安装Slack所需时间的一小部分，就可以从头开始构建一个正常运行的开发环境。如果开发环境崩溃，比如太落后，或者测试数据损坏，工程师也可以快速创建新的环境。标准化的开发环境另外，切换到Codespaces可以解决一些非常现实的问题。它消除了本地开发环境的脆弱性和单轨模型，同时也改善了GitHub开发者的体验。当我第一次切换到Codespaces时，我使用了一个8核、16GBRAM的VM。本来有这些配置就够了，但是GitHub运行的网络是由不同的服务组成的，消耗很大。所以后来换成32核64GBRAM的VM，每个工程师的配置都升级了。
