来源:GitHub
编辑:小云Priscilla
【新智元介绍】GitHub 最近宣布,他们将迁移到去年5 月发布的Codespaces。目前,Codespaces 由具有32 个内核和64 GB RAM 的虚拟机组成。您可以在几秒钟内主动克隆和启动存储库,以便您可以尽快与您的团队共享您的开发环境。 Github 宣布迁移到Codespaces。
GitHub 通过其博客通知开发人员:
扩展到GitHub Teams 和Enterprise(云)计划
开始广泛部署Codespaces(一种基于浏览器的编码环境)。
这家微软旗下的公司还宣布,它在内部做了以下工作:
从MacOS 模式迁移到代码空间
后者是目前GitHub 的默认开发环境。
GitHub 去年5 月首次发布了Codespaces,作为一个具有所有常见GitHub 功能的平台。
云托管开发环境。
它本质上由Microsoft 的Visual Studio Code 提供支持,该代码自2023 年以来一直作为基于Web 的编辑器提供,并于去年更名为Visual Studio Codespaces。
微软还在9 月份确认将把Visual Studio Codespaces 集成到GitHub Codespaces 中。
GitHub 的代码空间最初作为面向个人用户的“私人测试版”发布,但现在团队或企业(不包括自托管)计划的所有公司都可以在其GitHub 设置中主动使用代码空间。您现在可以启用代码空间并使用它们。在以下地点:所有私有存储库。
通过将编码环境引入云端,开发人员可以更轻松地加入项目并进行协作。
以最少的配置开始编码。
在过去14 年里,GitHub.com (github/github) 背后的核心存储库已收到超过100 万次提交。这些提交大部分来自在macOS 上构建和测试的开发人员。
如果不起作用,请更改它。将GitHub 迁移到Codespaces 可以解决开发人员环境中的各种问题。
想法有多理想,实现起来有多困难。
GitHub.com 存储库几乎占用了100% 的磁盘空间
13GB。
只是简单地
克隆存储库
,嘭,20分钟过去了。
与依赖项配置相结合,引导您在GitHub.com 上的代码空间。
45分钟过去了。
尽管存储库已成功安装在代码空间中,但应用程序尚未运行。
14 年来,以macOS 为中心的想法已经被浪费了。
但为什么强大的工程团队会如此轻易放弃呢?
他们开始质疑自己的假设并在源代码级别进行工作。
将GitHub 开发与macOS 分开。
最后,虽然它很慢,但它至少使GitHub.com 代码空间在你的Linux 主机上可用,允许你从Visual Studio Code 连接到它并提供一些工作。
看看下面的团队
如何实现“超快”的云开发环境。
从45 分钟到5 分钟
使用代码空间的目的是能够:
按需提供开发环境
,分支与代码空间之间的映射约为1:1。
为了支持基于任务的工作流程,团队希望能够:
“可以使用”。
虽然球队对45分钟并不满意,但这个时间长度还是给人希望。
首先要做的是
更改Codespaces 克隆github/github 的方式。
Codespaces 现在在配置期间执行浅克隆而不是执行完整克隆。
然后在使用最新提交创建代码空间后在后台运行非浅存储库历史记录。
这样,克隆时间将是:
从20分钟缩短到90秒!
下一个需要改进的点是
缓存支持GitHub.com 的软件和服务网络。
除了传统的基于Gemfile 的依赖项之外,它还包括用C、Go 和定制的Ruby 编写的服务。
团队想出了一个解决方案。
让GitHub Action 每天晚上午夜静默运行。
当然,克隆存储库、引导依赖项,然后构建并推送生成的Docker 映像。
发布的镜像作为github/github 上devcontainer-config-as-code 的基础镜像,构成Codespaces 环境。
立即重新加载,在浏览器中预览更改,并与团队成员共享私有和公共端口。
仅这两项更改(以及一些应用程序和服务级别的优化)就可以加快GitHub.com 代码空间的创建时间。
时间从45 分钟缩短至5 分钟。
但是GitHub这个工程团队真的很厉害。
他们觉得5分钟距离“准备好使用”的目标还有很远的距离。
尽管浅克隆方法对于在5 到10 秒内快速启动代码区域仍然非常有用,但在某些情况下仍然需要完整克隆。
因此团队认为:
提前克隆并引导存储库
毛织物?
只思考而不采取行动永远是不好的。
预构建:进入代码空间池,完全克隆和引导,并等待开发人员联系。
最后,您现在可以创建可靠的、预配置的代码空间。
和,
10秒内
准备好了。
与传统的Slack 实施相比,即使是新员工现在也可以在更短的时间内实施。
从零开始
进入正常运行的开发环境。
如果开发环境由于延迟或测试数据损坏而崩溃,工程师可以快速创建新环境。
标准化的开发环境
此外,切换到Codespaces 可以解决一些非常现实的问题。
这不仅消除了本地开发环境和单轨模型的漏洞,还改善了GitHub开发者的体验。
当我第一次切换到Codespaces 时,我使用了8 核、16 GB RAM 的虚拟机。
本来这些配置就足够了,但是GitHub运营的网络由各种服务组成,需要花费很多钱。
所以后来改成了
32 核、64GB RAM 虚拟机
,每位工程师的配置都得到了升级。
参考:
https://github.blog/2023-08-11-githubs-engineering-team-moved-codespaces/
https://github.com/features/codespaces
本文和图片来自网络,不代表火豚游戏立场,如若侵权请联系我们删除:https://www.huotun.com/game/651003.html