我已经在Chromebook上做了两年软件开发。它配备了16GB内存、512GB固态硬盘、宽显示屏,安装的是ChromeOS,有网络连接。这是我职业生涯中最有成效的时期。在这篇文章里,让我带你一起做一次旅行,从终端时代(通过终端访问共享服务器的算力)开始,到桌面/笔记本电脑时代(算力移到了个人电脑上),再到现在——笔记本电脑只是一个薄薄的层,我们通过它来访问共享(云端)服务器的算力(“回归”到终端时代)。
软件开发生命周期(SDLC)包括以下五个阶段:
SDLC的5个阶段
在早期,我们以会议和纸张为媒介来收集需求。我们在白板上设计软件,在台式电脑上开发和测试源代码,并将其部署到内部的服务器,还要维护这些应用程序。对我来说,这些已经是20年前的事了,听起来就像老古董一样——但对其他很多人来说,有很多东西现在仍然在用。
我们在线下走过这些SDLC阶段,其中最具“现代感”的是“实现”阶段,开发人员通过电脑终端访问互联网,搜索问题的答案、开发软件或与志同道合的人一起参与IRC频道。
作为实现阶段的一部分,每个开发人员都遵循(文档化的)指示来搭建他们的个人开发环境。这些指示看起来像这样:
软件开发是一项不断发生变化的工作,源代码几乎每天都在发生变化,本地开发环境也需要经常做出相应的调整。
对于现有的开发者来说,开发环境的变化是增量式的:安装新插件、升级到依赖项的最新版本或执行临时脚本。如果你和我有类似的经历,那你就应该知道,“第一天:开发配置”wiki页往往会被忽略,但这样不会有什么问题,因为它不会影响到任何人。增量式的变化可以在日常站会上或通过即时消息传递平台进行沟通。
接下来是汉娜的故事。她最近受邀加入新团队,她对第一天的工作感到很兴奋,希望能够尽快开始工作。她打开了“第一天:开发配置”wiki页,一边照着上面写的做,一边感激团队记录了这些步骤。第8个步骤有问题,一个团队成员帮她把问题解决了。在后续的流程中一直重复着这种模式,随着时间的流逝,第一天的工作结束了,但她并没有开始时那么兴奋……
因为互联网的发展,SaaS解决方案给软件开发团队的日常工作带来了重大变化。通过实时协作和即时反馈,过去需要手工和离线完成的工作现在可以在网上更高效地完成。
如今,SDLC的需求、设计、测试和维护阶段通常都在云端进行。无论一个业务是迁移到云端还是诞生在云端(即所谓的云原生业务),趋势都非常明显:云都将继续存在,而SDLC也将采用和适应这种创新,除了实现阶段……
回看SDLC,这一次我们重点关注哪些阶段是在云端完成以及哪些(还)不是。
除了实现之外的所有阶段,我们都使用浏览器作为终端来访问云端的软件。实现阶段被抛在了后面,其他阶段都在不断创新。现如今,全球的开发团队为了能够快速地将源代码推送到云端,都在使用强大且昂贵的硬件来编写和编译源代码,而且每隔几年就要升级一次硬件。
随着云计算在众多行业、流程和我们的日常生活中扮演着越来越重要的角色,是时候提出这个问题了:
实现阶段究竟怎么了?
我们要问自己两个同样重要的问题:
首先,实现阶段之所以落后,是因为缺乏可用且易用的解决方案。尽管已经有Cloud9、code-server和其他可能存在的解决方案,但它们似乎没有得到广泛应用。
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镜像的修改都成了版本控制历史的一部分,也就不会不知道谁在什么时候修改了什么。
假设你的同事指派你来评审某个PR。启用Gitpod的预构建特性后,它会自动准备工作区(下载PR代码、安装依赖项),当你打开PR工作区时就可以立马进行评审和测试了。
你是否曾经一边看着PR一边对自己说“这个看起来不错”,然后留下一个LGTM(Looks Good Tt Me),但没有实际去测试一下代码?是的,我们都有过这样的经历。Gitpod提供了一个内置的代码评审功能,方便我们评审代码和添加评论。如果要获得更高的效率,我们还可以配置Gitpod,让它添加PR注释,其中包含指向带有这个PR代码变更的工作区链接。
作为评审人员,你现在的工作流程这样的:打开PR,单击链接,评审和测试代码。
并行的工作区可以让我在不中断开发的情况下评审代码,这一点我很喜欢。这样就不需要使用“WIP:临时提交”之类的消息进行临时提交,也不需要为了与团队成员进行结对编程而切换分支(保存临时更改)。我们只需要在不同的浏览器选项卡中打开一个新的工作区,然后与团队成员共享这个工作区——甚至可以远程共享。完成评审后,关闭浏览器选项卡,你就可以回到自己的工作区。
最后,VS Code用户可以安装自己喜欢的插件,它们会自动应用到所有工作区。不管你是在笔记本电脑上还是其他地方,只要你用自己的帐户登录Gitpod,就可以使用这些插件。
你有没有建议团队成员使用特定的插件来提高工作效率?如果有,可以在项目级别配置这些插件,所有参与项目的人都可以自动使用这些插件。
你所需要的只是一个代码库URL。在GitHub或GitLab上创建一个新的代码库,并确保使用README文件初始化代码库。或者,你也可以使用已有的代码库!
为新代码库启用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后就可以进行评审了:
然后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。
原文链接:
领取专属 10元无门槛券
私享最新 技术干货