本文要点：
搭建和维护一致的开发环境根本不会增加任何业务价值，它可能是一项耗时且枯燥的工作，开发人员不应该花时间在这个上面。
除了“开发/实现/编码”之外，个人和企业在软件开发生命周期的大部分时间都应该利用好云平台和 SaaS 产品。
Eclipse Theia 是一个可扩展的平台，用于开发多语言的云和桌面 IDE，谷歌、Eclipse Che 和 Gitpod 都用它来提供基于云的开发环境。
想象一下，开始一个项目就像在浏览器中打开一个 URL 那样简单——确切地说，这不再是一个梦想，它已经变成了现实。
我已经在 Chromebook 上做了两年软件开发。它配备了 16GB 内存、512GB 固态硬盘、宽显示屏，安装的是 ChromeOS，有网络连接。这是我职业生涯中最有成效的时期。在这篇文章里，让我带你一起做一次旅行，从终端时代（通过终端访问共享服务器的算力）开始，到桌面/笔记本电脑时代（算力移到了个人电脑上），再到现在——笔记本电脑只是一个薄薄的层，我们通过它来访问共享（云端）服务器的算力（“回归”到终端时代）。
纸张、白板、会议和自有服务器
软件开发生命周期（SDLC）包括以下五个阶段：
SDLC 的 5 个阶段
在早期，我们以会议和纸张为媒介来收集需求。我们在白板上设计软件，在台式电脑上开发和测试源代码，并将其部署到内部的服务器，还要维护这些应用程序。对我来说，这些已经是 20 年前的事了，听起来就像老古董一样——但对其他很多人来说，有很多东西现在仍然在用。
我们在线下走过这些 SDLC 阶段，其中最具“现代感”的是“实现”阶段，开发人员通过电脑终端访问互联网，搜索问题的答案、开发软件或与志同道合的人一起参与 IRC 频道。
实现——最初的挑战
作为实现阶段的一部分，每个开发人员都遵循（文档化的）指示来搭建他们的个人开发环境。这些指示看起来像这样：
安装编辑器 X，添加插件 Y 和 Z；
下载源代码；
安装语言 SDK 和依赖项；
本地编译和运行软件。
软件开发是一项不断发生变化的工作，源代码几乎每天都在发生变化，本地开发环境也需要经常做出相应的调整。
对于现有的开发者来说，开发环境的变化是增量式的：安装新插件、升级到依赖项的最新版本或执行临时脚本。如果你和我有类似的经历，那你就应该知道，“第一天：开发配置”wiki 页往往会被忽略，但这样不会有什么问题，因为它不会影响到任何人。增量式的变化可以在日常站会上或通过即时消息传递平台进行沟通。
接下来是汉娜的故事。她最近受邀加入新团队，她对第一天的工作感到很兴奋，希望能够尽快开始工作。她打开了“第一天：开发配置”wiki 页，一边照着上面写的做，一边感激团队记录了这些步骤。第 8 个步骤有问题，一个团队成员帮她把问题解决了。在后续的流程中一直重复着这种模式，随着时间的流逝，第一天的工作结束了，但她并没有开始时那么兴奋……
向云端迁移
因为互联网的发展，SaaS 解决方案给软件开发团队的日常工作带来了重大变化。通过实时协作和即时反馈，过去需要手工和离线完成的工作现在可以在网上更高效地完成。
如今，SDLC 的需求、设计、测试和维护阶段通常都在云端进行。无论一个业务是迁移到云端还是诞生在云端（即所谓的云原生业务），趋势都非常明显：云都将继续存在，而 SDLC 也将采用和适应这种创新，除了实现阶段……
“实现”阶段怎么了？
回看 SDLC，这一次我们重点关注哪些阶段是在云端完成以及哪些（还）不是。
除了实现之外的所有阶段，我们都使用浏览器作为终端来访问云端的软件。实现阶段被抛在了后面，其他阶段都在不断创新。现如今，全球的开发团队为了能够快速地将源代码推送到云端，都在使用强大且昂贵的硬件来编写和编译源代码，而且每隔几年就要升级一次硬件。
随着云计算在众多行业、流程和我们的日常生活中扮演着越来越重要的角色，是时候提出这个问题了：
实现阶段究竟怎么了？
我们要问自己两个同样重要的问题:
为什么我们仍然需要高配置的笔记本电脑来开发软件？
为什么把实现阶段迁移到云端会如此困难？
首先，实现阶段之所以落后，是因为缺乏可用且易用的解决方案。尽管已经有 Cloud9、code-server 和其他可能存在的解决方案，但它们似乎没有得到广泛应用。
Eclipse Theia 和 Gitpod
Eclipse Theia为我们提供了一个开源的“用最先进的 Web 技术开发多语言云和桌面 IDE 的平台”。Google Cloud、Eclipse Che和Gitpod已经在使用 Theia。
Gitpod 完全改变了我的软件开发方式。作为一名 Chromebook 用户，我的大部分日常任务已经是在云端完成的。我一直梦想着有一天不再需要在本地安装应用程序！虽然 Chromebook 支持 Linux 应用程序，可以使用 VS Code，但仍然需要在本地安装软件。
有了 Gitpod，你可以这样修改你的“第一天：开发配置”wiki 页：
第一步和最后一步：打开 gitpod.io/#https://github.com/your-org/your-repository
实际上，你可以删除 wiki 页，将这个链接添加到项目的 README.md 文件中，把文档和源代码放在一起。
单击链接就可以启动开发工作区。还记得汉娜吗？她现在的入职经历充满了乐趣，真的令人感到兴奋。新的团队成员可以在几分钟内（而不是几天）开始工作！
将.gitpod.yml 配置文件放在项目根目录下，你就可以访问下述的各种附加特性。
用 Docker 镜像来保持一致性
如果你的项目需要使用第三方工具或进行定制化，可以提供一个自定义 Docker 镜像。在配置好了之后，每个新工作区都是基于同样的镜像，并且当镜像发生变化，所有的变化都将在开发人员下一次打开工作区时生效。另外一个好处是，对 Docker 镜像的修改都成了版本控制历史的一部分，也就不会不知道谁在什么时候修改了什么。
预先构建的工作区
假设你的同事指派你来评审某个 PR。启用 Gitpod 的预构建特性后，它会自动准备工作区（下载 PR 代码、安装依赖项），当你打开 PR 工作区时就可以立马进行评审和测试了。
内置的代码评审功能
你是否曾经一边看着 PR 一边对自己说“这个看起来不错”，然后留下一个 LGTM（Looks Good Tt Me），但没有实际去测试一下代码？是的，我们都有过这样的经历。Gitpod 提供了一个内置的代码评审功能，方便我们评审代码和添加评论。如果要获得更高的效率，我们还可以配置 Gitpod，让它添加 PR 注释，其中包含指向带有这个 PR 代码变更的工作区链接。
作为评审人员，你现在的工作流程这样的：打开 PR，单击链接，评审和测试代码。
并行和共享的工作区
并行的工作区可以让我在不中断开发的情况下评审代码，这一点我很喜欢。这样就不需要使用“WIP:临时提交”之类的消息进行临时提交，也不需要为了与团队成员进行结对编程而切换分支（保存临时更改）。我们只需要在不同的浏览器选项卡中打开一个新的工作区，然后与团队成员共享这个工作区——甚至可以远程共享。完成评审后，关闭浏览器选项卡，你就可以回到自己的工作区。
支持 VS Code 扩展
最后，VS Code 用户可以安装自己喜欢的插件，它们会自动应用到所有工作区。不管你是在笔记本电脑上还是其他地方，只要你用自己的帐户登录 Gitpod，就可以使用这些插件。
你有没有建议团队成员使用特定的插件来提高工作效率？如果有，可以在项目级别配置这些插件，所有参与项目的人都可以自动使用这些插件。
如何开始
你所需要的只是一个代码库 URL。在 GitHub 或 GitLab 上创建一个新的代码库，并确保使用 README 文件初始化代码库。或者，你也可以使用已有的代码库！
为新代码库启用 Gitpod 环境:
复制代码库 URL：如果没有可用的 URL，可以使用这个URL；
打开一个新的浏览器选项卡；
在地址栏中敲入“gitpod.io/#”，并添加“https://your-repository-url”：例如https://gitpod.io/#https://github.com/mikenikles/gitpod-getting-started;
使用 GitHub 账号登录，启动工作区；
出现提示时，授权 Gitpod 访问你的 GitHub 或 GitLab 账户：不需要新的 Gitpod 用户名和密码；
接受 Gitpod 的服务条款，点击创建免费帐户。
几秒钟后，你的 Gitpod 环境就启动并开始运行了。
Gitpod 项目配置
会有一个通知提示你要不要进行 Gitpod 项目配置。
单击“Setup Project”，会出现一个设置向导，引导你进行后续的流程。
步骤 1：创建 .gitpod.yml
单击 Create .gitpod.yml，创建一个最基本的配置文件。
步骤 2：修改基础镜像
这个时候可以修改基础镜像，比如已安装的 MySQL。你也可以选择自定义镜像，特别是业务和项目的自定义镜像。
步骤 3：更新 README
单击 Update Readme 添加 Gitpod badge，任何一个参与这个项目的人都可以通过单击这个 badge 启动 Gitpod 环境。
步骤 4：测试驱动配置
注意：如果你使用的是示例里提供的 URL，因为你不是这个项目的贡献者，会被询问对项目进行 fork。不过如果你使用的是自己的项目，就不需要 fork，直接推送即可。
单击 Push to Branch & Start Workspace，Gitpod 会发起权限请求。单击 Grant Permissions，在新窗口中单击 Authorize gitpod-io。然后单击 OK 关闭授权窗口，最后关闭浏览器选项卡。
步骤 5：创建 PR
这是最后一步，Gitpod 提供了一个界面，用于创建一个包含 Gitpod 配置的新 PR。单击 Create pull request，打开 PR。
在这里可以看到一些最基本的配置。
代码评审
打开 PR 后就可以进行评审了：
在浏览器上找到 PR；
拷贝 PR 的 URL；
在地址栏中敲入“gitpod.io/#”，并加上“https://your-pull-request-url”，例如 gitpod.io/#https://github.com/mikenikles/gitpod-getting-started/pull/1。
然后 Gitpod 就会启动并运行，然后就可以开始评审、测试和合并了。
评审人员可以直接在 IDE 里添加评论：
接下来
在合并 PR 之后，其他参与项目的人就可以单击项目 README 的 Gitpod Ready-to-code badge 开始开发项目。
结论
Eclipse Theia 最近发布了 1.0 版本。在我看来，它标志着软件开发生命周期剩下的最后一个阶段——实现阶段开始被迁移到云端。
我预计，在家办公的文化对世界各地的企业将变得更加重要，因为他们都在寻找最优秀的人才，而这些人才不一定住在办公室附近。有了 Eclipse Theia 和 Gitpod，我们向在云端进行完整的端到端开发又迈进了一大步。
现在，只需要一个简单的单击就可以开始开发，你可以考虑下一步的事情：项目中还有什么是可以改进的，让第一天来上班的团队成员在回家之前就可以写代码？
作者简介：
Mike Nikles 是一位很重视效率和团队士气的软件架构师。他关注可伸缩的云原生解决方案，主要与部署在谷歌云平台上的 JavaScript/Typescript 有关。二十年来，Mike 一直在创业公司或大公司担任团队负责人，帮助很多创新想法落地。你可以在Twitter、LinkedIn或www.mikenikles.com上找到 Mike。
原文链接：
https://www.infoq.com/articles/cloud-based-development/
分布式云行业实践指南（2023）
业内首个分布式云行业实践方法论、工具箱。
评论