很多年前的一天,我在 TypeScript 仓库下创建了一个 issue:微软打算拿 Monaco 来干嘛?接着第二天微软就发布了 VS Code。这个巧合我吹了五年还孜孜不倦。
因为已经用上了 TypeScript,我们也顺利将当时团队主要使用地编辑器从 Atom 切换到了 VS Code 0.1,应该是国内最早一批 VS Code 用户了。
这两年来,随着当前项目代码规模的不断扩大,我开始寻找利用服务器计算资源的开发方案来改善开发体验,尝试了诸如 StackBlitz 这样的方案,但一直还是希望找到完整的 VS Code 在线部署方案。直到遇到了 code-server,然后微软就冷不丁发布了 Remote Development。心疼 code-server 三秒钟。
一周后,我们很快搭建起来了一套简易的多用户 VS Code 方案,手动配置 docker compose 文件为同事每人分配了一个容器和 SSH 端口,成了或许是国内第一批使用 VS Code Remote Development 的团队。
当时我们考虑了一种应用场景,也就是一个分支对应一个远程工作空间,创建工作空间后自动克隆和初始化项目,完成后释放远程工作空间。当然后来的事情大家都知道了,微软发布了 Visual Studio Online,覆盖了相似的场景。
为啥要眨眼?因为当时我们已经用上自己折腾出的升级方案 remote-workspace 挺久了,说不定是 Visual Studio Online 团队以外第一批使用 VS Code Remote Development 按功能分支创建远程工作空间的团队。
开发工作流
我们根据开发类型和改动大小其实有几个不同的开发工作流,以常规开发工作流为例:
开发
首先,任务开发负责人以任务编号为分支名称创建远程工作空间:
我们将常见项目添加到了共用的模板中,简单选择就可以完成工作空间配置,支持同时初始化多个项目,方便跨项目的开发任务。
对于我们的主项目,整个初始化大约需要 40 秒。这个过程包含了代码克隆,包安装,部分代码编译和示例数据生成。我们启用了跨容器的本地 Git 对象共享,包缓存等以优化初始化时间,对于一些小项目则通常能在几秒内完成。
聪明的同学可能注意到了上面的“tunnel”。打开某个工作空间时,会自动转发配置的端口。偶尔我们也会不打开项目,直接 tunnel 其他同事的工作空间,测试或参与调试正在开发中的版本。
代码评审
完成开发后,同事会进行代码评审。通常而言,我们会先在 GitLab 中查看 MR;对于有复杂度的改动,则会打开对应任务的远程工作空间,使用 VS Code 进行查看:毕竟 GitLab 上看 diff 很多时候都只能充当人肉 prettier,检查下代码风格。
除了可以使用到完整的语言服务,快速在代码中导航跳转以外,还可以更方便地修改、查看效果。同事开发过程中留下的测试数据通常也会方便代码评审人对功能进行测试。
分支对比我们使用的是 GitLens 提供的 Compare Ancestry with Working Tree:
代码重构(修改)
需求是做不完的,为了节约开发和代码评审人双方的时间,对于一些直接改比退回去快很多的修改,则不再退回开发节点,而是直接由评审人修改和提交。比如:
- 重命名。
- 小重构,但负责开发的同学可能项目内外经验不能很好地快速完成相关重构。
交付和收尾
至此,一个远程工作空间的使命就完成了,任务负责人会删除远程空间释放相关资源。
总结
虽然叫做升级方案,但 remote-workspace 项目定位还是一个快速成型的内部工具,加上 VS Code Remote Development 的客观特点,整个体验还是有好有坏。
优点
- 无需频繁切换分支,多个开发任务可以交替进行。
- 提高 code review 质量,避免因为 GitLab 跳转引用和修改不方便就降级成 coding style review。
- 开发中的代码也在云端,方便多个开发设备切换。
- 统一的开发环境,无需折腾项目运行环境。
- 较低的开发机配置要求,延长笔记本风扇的寿命。
- 远程办公友好。
缺点
- 延迟还是较为明显。
- 需要较为稳定的网络,飞机高铁上就别想用了。
- 有一些场景的使用可能会变得复杂,比如 E2E 测试。
- 存在一些明显的安全隐患。
Makeflow (makeflow.com) 是以流程为核心的项目管理工具,让研发团队能更容易地落地和改善工作流,提升任务流转体验及效率。如果你正为了研发流程停留在口头讨论、无法落实而烦恼,Makeflow 或许是一个可以尝试的选项。如果你认为 Makeflow 缺少了某些必要的特性,或者有任何建议反馈,可以通过 GitHub、语雀或页面客服与我们建立连接。