GitHub.com工程团队应用Codespaces构建开发环境

随着GitHub的规模不断扩张,程序代码库也越来越庞大,为了让GitHub新的开发成员快速上手,以及提供更方便的开发环境,GitHub工程团队从原先以macOS为中心的开发模型,转而使用Codespaces,并且采用预构建等方法,将启动开发环境的时间缩减至10秒钟。另外,GitHub也宣布,开始向Team和Enterprise Cloud方案用户提供Codespaces,并扩展个人方案用户的测试规模。

距离GitHub.com第一个程序代码提交已经14年,在这14年间,GitHub.com核心存储库已经收到超过一百万次提交,而这些提交绝大多数,来自在macOS上构建和测试的开发人员,而随着GitHub开发平台不断发展,macOS模型已经不适用。

多年来,GitHub采用一种称为Scripts-to-rule-them-all的方法,让新加入开发团队的成员,可以复制github/github存储库、执行设置、加载脚本,并且能够在半天的时间,就成功于本地执行实例执行GitHub.com,当流程无法顺利进行,则脚本会自动帮新进成员连接到内部支持人员,以快速解决问题。

但GitHub提到,尽管他们做出许多努力,但本地端开发环境仍然非常脆弱容易出错,有时候甚至需要开发者花数小时的时间来恢复开发环境,而且这种情形并不少见,他们甚至特别编写了一个称为–nuke-from-orbit的脚本来解决这类问题,该脚本会尝试删除设置,尽可能将本地环境恢复成为良好状态。

另外,GitHub认为,单一上下文且定制的本地端开发环境,与现在GitHub的运营需求,包含即时启动、从任何地方访问的哲学格格不入,开发者在跨多个项目的多个分支上协作更是不便,当新分支加入新的相依项目、发布架构更改或是从不同的SHA分支的时候,常需要花费45分钟以上的等待时间。

在GitHub构建Codespaces时,他们发现不少企业遭遇相同的问题,而这些企业也在组织内置构类似Codespaces的平台,来解决这类问题,GitHub提到,在大规模的组织中,消除这类型的生产力损失,将会是明显提升生产力的好方法。

Codespaces是GitHub在2020年发布的新服务,让用户可以直接在网页IDE编辑程序代码,并且使用所有VS Code浏览器版本的所有功能,包括配置程序代码和相依项目等功能,其一大优点是可以简单地切换开发环境。官方提到,将GitHub.com程序代码库搬到Codespaces,解决了GitHub开发环境现有的缺点。

Codespaces让开发者依据手上任务,按需获取开发环境,不过,这也带来新的问题,基于任务的工作流程,需要接近即时的速度,但因为光是简单地复制GitHub.com存储库13 GB的文件,就需要20分钟,再加上依赖性配置设置,要完整加载一个GitHub.com程序代码空间,需要花费45分钟,这个时间无法满足基于任务的开发环境条件。

因此GitHub进行了一些方法来加速获取程序代码库的速度,首先是改变Codespaces复制的方法,让Codespaces进行浅层复制,不在配置时进行完整复制,仅在最新的程序代码提交,Codespace创建之后,才会在背景进行非浅层复制,这样可使得一开始复制时间,从20分钟降为90秒。同时,GitHub每晚还会执行一个GitHub Action,将存储库、相依项目和构建等文件打包成为镜像文件,这个镜像文件被用作github/github的开发容器,以配置即程序代码的方式构建Codespaces环境。

这两项改变以及一些应用和服务层级的优化,使得GitHub.com程序代码空间的创建时间,从45分钟缩短至5分钟。虽然5分钟已经是很大的进步了,但是GitHub仍不满足,因此他们又采用预构建方法,在Codespaces池中准备事先启动的开发环境,等待需要的开发者连接访问,这样的方法可以让开发者在10秒内,立即使用到GitHub.com开发环境。

在Codespaces中,GitHub能够简单地配置每个开发者所使用的机器规格,一开始使用8核心、16 GB内存的虚拟机,为了符合更多样服务的需求,因此进一步提高机器规格到32核心、64 GB内存的虚拟机,GitHub提到,这个过程只需要更改一行配置,就能够立刻升级每个工程师的机器。

除了使用VS Code作为主要来操作程序代码空间的工具,原本使用Vim和Emacs的用户,也能够使用程序代码空间,GitHub借由升级预构建镜像文件,让该镜像文件使用GitHub公钥,并且打开22连接端口,并从端口口转送程序代码空间,让不使用图形接口编辑器的用户也可以用到Codespaces。

发表评论