博客

• 博客列表
• 软件工程的第一性原理
• 聊聊平台工程
• 没有使用IaC的DevOps系统都是耍流氓
• SmartMeetup(S01E05) - 10分钟搭建开源免费的私有CloudIDE服务
• HashiCrop和Forrester为企业云战略提供的4条建议
• SmartMeetup(S01E04) - 仅有50Mb的小工具搞定大厂才能玩的CloudIDE
• 市值200亿美金的Slack：远程开发如何提高开发效率
• 开放原子开源峰会 - SmartIDE正式开源并发布v1.0版本
• 埃隆马斯克五步工作法
• 【开源云原生大会】现场演示：k8s套娃开发调试dapr应用
• 为什么Dapr是比SpringCloud和Istio更优雅的微服务框架？
• README.exe
• 版本日志
• SmartIDE v1.0.25 统一配置文件和Codespaces for Azure DevOps插件
• SmartIDE v1.0.23 一个非常不敏捷的发布
• SmartIDE v0.1.19 - Gitee GVP、工作区策略、类虚拟机镜像VMLC、Server安装手册
• SmartIDE v0.1.18 已经发布 - 阿里OpenSumi采用SmartIDE插件市场提速10倍、Dapr和Jupyter支持、CLI k8s支持
• SmartIDE v0.1.17 已经发布 - 模版库远程模式和插件市场公测
• SmartIDE v0.1.16 已经发布 - 支持阿里&蚂蚁开源的国产 IDE OpenSumi
• SmartIDE Sprint 14 Server版内测 (v0.1.14)
• SmartIDE Sprint 9 (v0.1.9)
• SmartIDE 产品发布 (v0.1.7)
• SmartIDE v0.1.5 发布说明
• SmartIDE v0.1.2 发布说明

博客列表

软件工程的第一性原理

一直都想写这样一篇文章来聊一聊我对软件工程的看法，粗略算来我从事软件工程这件事情已经将近18个年头。很多人并不理解软件工程和软件开发的区别，用一个简单的类比来说明一下：如果说软件开发人员是淘金者，那么从事软件工程的人员就是卖牛仔裤的。是的，软件工程就是为软件开发人员提供最好的方法，工具和实践的学科。要做好软件工程这件事情首先要做的就是要理解到底什么是软件开发，也就是说软件工程的从业者必须对自己所服务的对象有正确理解，才能摸清其中的规律，从而为软件开发人员提供符合自然规律的方法，工具和实践 — 这个所谓的规律就是我今天想跟大家聊的内容：软件工程的第一性原理。

第一性原理这个词被埃隆马斯克带火了，其基本含义就是事物的根本性规律，马斯克经常说自己对物理学很痴迷就是因为物理其实研究的就是世间万物的根本性规律，从这个规律出发所做出的判断和决策就是符合规律的，也是一定可以实现的。相反，如果做不符合规律的事情，那么结果被各种困境缠绕，无法脱身。所谓的适者生存，就是这样一个简单的道理。

但是，规律的做法不一定就是简单方便的做法，事实上一般的情况恰恰相反，符合自然规律的做法往往都更加困难，违背基本的人性。举个简单例子，我们都知道要获得健康的身体就要坚持规律的作息，持续的锻炼身体并且科学的饮食；而实际的情况是我们总有理由去熬夜，总会在计划好的锻炼时间偷懒，高糖高碳水的冰淇淋和蛋糕也永远比蔬菜沙拉更加吸引我们，这就是人性。

软件第一性原理第一定律：软件是虚拟的

软件是一个虚拟物品，这就是软件工程的第一性原理，认识到这一点你才能真正理解精益敏捷、理解DevOps和持续交付，理解研发效能，理解平台工程，理解任何为了软件而存在的方法，工具和实践。 等等，软件是一个虚拟物品，这不是废话吗？是的，只有符合自然规律的描述才能被称之为废话，因为这个第一性原理本来就不神秘，本来就在你的身边。这就好像牛顿的力学定律一样，说出来你也会觉得是废话，但是真的要把它解释清楚，那么你就成为牛顿了。是的，你和牛顿的距离就是一句废话。

地下室的故事

话说一家知名的房地产大厂有一位具备500年房地产从业经验的设计师，他设计大楼的经验年头甚至都比大楼存在的时间要长那么几十年，唯一的问题是这些设计师是个盲人。有一次这位设计师来到一座将要竣工的大楼面前，这座楼有50多层，已经进入到内装修阶段了。设计师在仔细检查了大楼的各项设施之后提出了自己专业的意见，这个大楼需要增加2层地下室。

你一定可以想象在场的项目经理，施工方和工人们惊吓的目光，感觉自己遇到了一个疯子。不过，类似的场景其实只是各个软件/互联网大厂的日常而已吧，这样的疯子每天都见，早就习惯了。

疯子错了吗？

当然没有，他只是发现了一个“底层”问题，但是并没有意识到这是个“底层”问题，因为他根本看不到这栋大楼。这就是软件，一个虚拟的大楼。

作为程序员，大家都懂软件的分层，数据/逻辑/界面这是基本的三层架构；实际中的软件往往比这要复杂的多。但是如果你尝试去给普通人解释，这将是一件非常有挑战的工作，恐怕要从Hello World讲起。

因为软件本身是一件虚拟物品，普通人很难通过常识判断软件的复杂性以及内部关系，造成严重的信息不对称，这是软件工程领域各种问题的原罪。

软件第一性原理第二定律：软件只能被制造一次

复制一款软件和复制一辆汽车的成本是完全不同的，这也是基于第一定律延续。复制一辆汽车需要从新投入原材料，人工和各种生产资料，但是复制一款软件只需要Ctrl-C加Ctrl-V就够了。软件开发团队所做的事情严格来说不是生产制造软件，而是在设计软件，因为生产制造是指重复产出同样的产品，而软件开发团队每次产出的都是不一样的产品。

瀑布模式就是个错误

设计是一项创造性活动，创造性活动的目标是无法被预先定义的，其最大的风险是创造了无用的产品，如果方向错了，所有的努力都只会加速死亡。既然生死未知，计划的意义何在，你在计划更好的生，还是计划更快的死？现实中的表现是软件经常延期，工作量估算不准确，开发过程经常遇到不可见问题，轻则延期重则推翻重做。这也是瀑布式开发模式为什么从根本上就是错的，瀑布式开发的一个基本假设就是目标是确定的。

既然瀑布本身就是错误，为什么仍然有那么多组织和团队仍然在使用这种模式呢？其实在本文一开始已经解释了原因，这就是蔬菜沙拉和奶油蛋糕的区别。瀑布模式虽然不符合软件工程的基本规律，但是它更加符合懒惰和规避变化的人性特点，因此大家会不自觉的选择奶油蛋糕。如果再考虑组织中僵化的流程，官僚的氛围以及各种利益的驱使因素，那么瀑布这种更加容易管理，更省心轻松的方式自然会受到欢迎，至于产出的软件是否有用，是否浪费了资源，开发人员是否痛苦不堪，这些都不重要。当然，前提是这个组织本身不依赖软件生存，对于一个数字化的组织或者强烈依赖软件运作的组织而言，产出无用的软件这一点就已经足够驱动他们选择蔬菜沙拉了。事实上，那些选择了奶油蛋糕的早就死于高血脂引起的心血管疾病和脑梗了。

敏捷只是个标签

倡导迭代式的敏捷开发模式为什么现在被大多数开发团队认可，原因就是敏捷从根本上承认了软件开发目标的不确定性，而不像瀑布模式那样非要去定义一个无法被定义的东西。精益思想里面的核心Build-Measure-Learn强调的也是在目标不确定的前提下，怎样通过不断的检视来识别问题，调整方向，最终达到目标。DevOps的三步工作法 1）建立流和系统化思维 2）建立反馈 3）建立持续实验和学习的文化，看上去是不是也异曲同工？这些方法和实践都诞生于软件工程领域，现在已经在很多非软件行业使用，其思想根基都是以上所述的软件第一性原理，都是为了应对客观规律而被总结出来，又在实际工作中被验证的方法。

软件工程的基本工作思路 - 粒度和解耦

软件这件事情，现在变得越来越重要。现在火热的所谓数字化，研发效能，平台工程，其根本都是在寻找最大化软件价值的方法而已，只不过关注的层面有所不同。数字化更加关注用户侧和业务价值，研发效能更加关注开发过程，而平台工程则强调用一个内部开发者平台（Internal Developer Platform, IDP）来承载具体的方法和实践。 1993年，被称为是互联网点火人的马克安德森（Marc Andreessen ）开发出了Mosaic浏览器，后来加入网景（Netscape）公司，开创了互联网时代。可以说，软件这件事情只有到了互联网出现以后才真正开始进入普通人的生活。2011年，马克安德森提出了 软件正在吞噬世界（software is eating the world） 的说法，同一年的1月21日腾讯推出了一款为智能终端提供的即时通讯软件，叫做微信。

随着软件规模的不断扩大，早期几个人就可以搞定的软件现在需要几百上千人协同完成，软件开发过程本身的问题也被放大，变成了影响组织生存发展的大问题。 从研发效能的层面，从软件第一性原理出发，我们需要确保在目标不确定，方法不确定，系统越来越复杂的前提下帮助企业取得成功，其基本思路只有2个：就是粒度和解耦。面对不确定目标最简单的应对方式就是将复杂问题简单化，对问题进行拆解，然后逐个攻克。 但是在拆解的过程中会带来一个副作用就是拆解后的单个问题确实简单了，但是问题的数量增加引起问题之间的依赖的副作用。因此我们需要解耦，采用各种管理和技术手段，让拆解后的问题可以被独立解决，而不是依赖其他问题。有关粒度和解耦的话题，请参考我的另外一篇文章 DevOps实施落地的2大法宝——粒度&解耦

解耦是一个非常难的话题，在软件工程领域，对这个问题的解决方式就是 基础设施即代码 （Infrastructure as Code, IaC）,IaC本身看上去是一个纯粹的工程方法/工具，实际其背后隐含了一个重要逻辑，就是如果要降低AB系统耦合，就要从他们依赖中提取共性，然后由第三方C来解决这个问题，如下图：

如果想详细了解IaC的概念以及落地方法，请参考我的另外一篇博客 没有使用IaC的DevOps系统都是耍流氓 。

软件工程随着软件在我们生活中变得日益重要而开始引起了越来越多人的关注，这个行业也非常善于创造概念，因此你会听到各种新鲜的词汇，包括在本文中提到的敏捷，精益，DevOps，平台工程，研发效能等等。但只要做的还是软件，就无法背离软件工程第一性原理的2条定律，记住粒度和解耦，落实IaC的工作方法，就一定能找到适合自己的模式，应对好自己的问题，在自己的领域中取得成就。

最后还想说一句话：这些方法都会帮助你登上高峰，但一定不是别人的那座。

本周二晚 SmartIDE Meetup 继续 本期话题：谁说CloudIDE就只能用浏览器访问，Hybrid模式远程工作区想用什么就用什么 B站直播预约通道已经开启，现在预约就有机会获得 价值3500元的JetBrains全系列激活码一个和SmartIDET恤2件

聊聊平台工程

最近InfoQ上的一篇文章火了 DevOps 已死，平台工程才是未来，事实证明标题党确实对营销很有效，但这也确实只是一篇营销文章而已，文章内容其实和标题大相径庭。这个标题极具误导性，文中作者的核心观点：开发者不想跟基础设施打交道，企业在发展过程中又需要控制自己的基础设施。只有平台工程，能将这两个相互矛盾的命题统一起来。 看上去非常有道理，但是在我仔细研究了原文之后发现其核心观点本身其实不攻自破，就连作者自己的文章之中也在不停的引用各种DevOps中已经存在的实践和方法，同时承认这些方法实践的有效性。

平台工程的来源和定义

作为IT行业研究的权威机构，Gatner在2022年8月发布的 Hype Cycle for Emerging Tech （技术趋势发展曲线）中提到了这个词汇：平台工程 Platform Engineering，从其所处的曲线位置大家可以判断这是一个将在2-5年内快速流行的技术。

平台工程社区的发起人 Luca Galante 在 platformengineering.org 对平台工程的描述（定义）是这样的：

平台工程是一门设计和构建工具链与工作流的学科。这些工具链和工作流可以为云原生时代的软件工程组织提供自助服务功能。平台工程师提供集成化产品，通常称为“内部开发平台（Internal Developer Platform - IDP）”，可以涵盖应用程序整个生命周期的所有操作需求。

这里面的关键词有2个：自助服务和内部开发平台。 平台工程的目标其实是为企业构建一个协助开发者完成软件交付过程中与核心业务逻辑开发无关的支撑类操作的平台。从这个角度来看，我相信大家一定感觉非常的不陌生。

实际上，在我从事软件工程 / 敏捷 / 精益 / DevOps 咨询服务将近20年的过程中，我所服务的所有开发团队都在构建这样一个平台。

DevOps真的死了吗？

对于这个问题，一句中国的古诗可以描述得非常贴切：

春蚕到死丝方尽，蜡炬成灰泪始干

如果企业没有在软件工程上下真功夫，没有敏捷和精益的方法指导，没有实施DevOps实践的经验积累，平台工程也只能是空中楼阁。实际的情况是，很多企业在不停的寻找所谓“创新”而忽略了基本功的锤炼。真正企业需要的研发系统，一定不仅仅是DevOps工具就能覆盖的，但没有DevOps也一定是不能覆盖的。

我记得曾经在上海拜访过某国有大型银行的研发中心，交流的主题是高大上的企业研发效能平台，当时参与交流的几位关键领导之外还有1位负责项目发布上线的工程师，在领导们介绍了他们当前的各种实践之后的感觉这是一个相当成熟的DevOps团队，流水线仪表盘都做的很到位，度量数据丰富扎实，MTTR看上去走势良好 …… 但是场面在这位工程师回答了我一个问题之后急转直下，我的问题是：你所负责的系统，如果你不来上班，其他人可以正常发布吗？答案是：不能。后来我觉得，跟领导交流还是要纯粹一点，让懂技术的人参与进来肯定会带歪主题。

这其实是大多数企业在落地DevOps研发效能时候的通病，光鲜亮丽的仪表盘背后其实是人力发电的空调系统。 其实DevOps的各种所谓文化，理论，实践都基于一个最基本的逻辑，就是基础设施即代码IaC。对于IaC的理解我们不能仅仅停留在字面意义上，其真正推动的其实是一个共享，协作，抽取共性的工作模式。有关IaC的详细分析，可以参考我的另外一篇博客：没有使用IaC的DevOps系统都是耍流氓。

很多企业还没有做好最基本的配置管理，分支管理，开发环境管理就开始要搞什么灰度发布，微服务架构。其实一个DevOps系统完全可以简单到一个 shell 脚本，当然也可以复杂到需要200人的团队去维护。关键是要 回到问题的本质，软件研发只是手段，不是目的，做出来的软件是给用户用的，不是拿来跑流水线做自动化测试出指标看度量数据的 。如果一个工具平台，不能让开发者获得自由，反而增加了各个角色之间的耦合，那么这种平台还不如没有。在那些被PMO吹上了天的DevOps平台过级认证的背后，我看到的是这些企业内部开发人员的怨声载道，本来可以简简单单，清清爽爽的开发，测试上线，现在变成了一堆高大上的平台，系统里面繁琐得找不到 “下一步” 按钮的流程。

DevOps可以死，在它燃烧掉所有的价值能量之后，在企业真正吸收了这些知识和实践之后，这时候真正可以锤炼抽取出对开发者有用的这样一个平台的话，那么也是死得其所。

一定要警惕专家

埃隆马斯克曾经在一次采访中说过：对于任何的需求都要谨慎，特别是那些来自所谓专家的建议，因为你可能因为他们的身份而停止了自己大脑的运转。 看看下面这几位专家的建议，我只能说：你们长的这么帅，我只能相信你们了。

Tammer Saleh: 从单体开始，逐步抽取出你的微服务

Stefan Tilkov：如果你的目标是微服务架构，那么就不要从单体开始

Simon Brown: 如果你做不出一个单体应用，你觉得你能搞定微服务吗？

开发不想做运维

回到作者的核心观点：开发者不想做运维工作！谁说DevOps就是让开发做运维工作了？谁又说持续改进就要让用户使用不稳定产品了？DevOps底层所需要的IaC的本质就是要创建一种机制，让开发和运维一起构建一个工具或者系统，双方都把公用能力贡献出来，简化双方的工作，即不是运维为开发服务，也不是开发要学习运维。

到了具体个体案例的时候，企业在实施DevOps过程中会受到领导者和实施者自己组织现状的种种制约，才会出现各种变形。问题根源不在方法，在于人。这就好像给你一把手枪，你可以用来主持正义也可以用来杀人越货，难道这是手枪的问题？

最后还是我常说的那句话：没有不适合DevOps的组织，只有不想做出改变的人！

参考资料

• https://platformengineering.org/blog/what-is-platform-engineering
• https://www.liatrio.com/blog/what-is-platform-engineering-the-concept-behind-the-term
• https://www.gartner.com/en/articles/what-is-platform-engineering
• https://web.devopstopologies.com/
• https://teamtopologies.com/

没有使用IaC的DevOps系统都是耍流氓

作为现代软件工程的基础实践，基础设施即代码（Infrastructure as Code, IaC）是云原生、容器、微服务以及DevOps背后的底层逻辑。应该说，以上所有这些技术或者实践都是以基础设施即代码为基本模式的一种或者多种方法的集合。基础设施即代码并不是一种特定的技术，而是一种解决问题的思路。本文将从基础设施即代码的含义，原则和落地方法三个层面来帮助你理解为什么没有使用IaC的DevOps系统都是耍流氓。

什么是IaC

基础设施即代码的目标是解决一个古老的问题：如何能够安全、稳定、快捷、高效得完成软件交付过程。注意这里的交付并不仅仅指将可部署的软件部署到最终的运行环境，而是更宽泛的概念上的交付，也就是将软件从一个看不见摸不到的想法或者创意，转变成用户可以操作并使用的一个系统。这个过程涉及软件创意的捕捉、设计、计划、开发、测试、部署和发布的全过程，也包括软件发布之后收集用户反馈重复启动以上过程的迭代。这个迭代在软件的整个生命周期里面会一直重复下去，直到这个软件不再有人使用，寿终正寝。

软件生命周期中的这个持续的迭代过程构成DevOps反馈环路的概念，在这个反馈环路的左右两端分别是Dev和Ops，而代码和基础设施正是Dev和Ops最重要的工件（Artifact），Dev维护代码，Ops维护基础设施。传统意义上，代码和基础设施是有明确的界限的，一般来说：代码特指应用代码，而基础设施则是除了应用以外（或者以下）的所有“基础”组件。

在云计算技术出现以前，硬件被普遍认为是一旦创建就无法改变的，就好像你购买一台电脑，如果希望更换其中的CPU，内部，磁盘以及网卡，那么都必须重新购买相应的组件并重新组装。云计算将计算资源（电脑）解耦成了可以随意组合的计算、存储和网络三种资源类型，允许用户根据需要自助的进行组合。其底层实现机制是将硬件软件化，比如：对象存储技术和软件定义网络（SDN）就是云计算的基础技术。硬件被软件化之后的结果就是我们可以通过配置来变更硬件的能力。这其实就是基础设施即代码的最基础的含义。

但是对于用户而言，其实并不关心所使用的软件到底运行在什么硬件，什么云上面。比如：对于用户的社交需求来说，微信就是社交需求的基础设施；对于需要编写文档的用户来说，WORD就是他的基础设施。相对于硬件，这其实是基础设施的另外一个极端含义，也就是：任何支撑用户完成某种操作的支撑能力，都可以成为用户这一类别操作的基础设施。

从这个极端含义的角度来说，以上环境堆栈中的任何一层都可能成为上层的基础设施。为了能够为上层提供类似云计算的自助化能力，都需要提供可配置性。为了满足这种可配置性的需要，IT行业里面就出现了容器化技术、Kubernetes、Terraform、Azure Resource Manager等等基础设施即代码的实现方式。其实这些技术解决的都是一个问题，也就是系统的可配置性问题。

IaC的实现原则

实现可配置性能力的方法很多，传统运维的做法其实很简单，就是通过脚本来自动化这个配置过程，让原本繁琐的配置过程自动化起来。

自动化脚本的方式虽然能够在一定程度上解决可配置问题，但是当系统变更频繁程度到达一定量级的时候，维护自动化脚本的工作量将会抵消自动化脚本所带来的效率提升，这个时候运维团队会发现采用人工处理的方式甚至比编写和维护自动化脚本更加高效。因此，在当今软件迭代速度越来越快的背景下，自动化脚本逐渐无法满足团队应对快速变化的市场的需要。我们需要一种能够能够允许团队轻松适应快速变化的环境维护方式，基础设施即代码（Infrastructure as Code, IaC）就是在这样的背景下诞生的。实际上，说诞生并不准确，IaC其实是工程师们在遇到问题之后持续改进的结果。

当维护自动化脚本的方式无法适应快速变化的市场需要的时候，如何让开发和运维团队解耦就变成了解决这个问题的核心。在上图左侧的工作模式中，问题的核心是开发和运维团队之间基于“请求-响应”的工作模式，这种工作模式让开发和运维团队相互依赖，无法独立的按照自己的节奏工作。为了解决这个问题，IaC借用了大规模软件架构设计中的分层原则，让那些需要被共享的能力变成通用组件，并在开发和运维之间共享这些组件，从而让本来互相依赖的两个团队变成依赖另外一个第三方组件。如下图：

为了能够通过第三方组件协同工作，IaC方式需要遵循几项关键原则

• 声明式（Declarative）：为能够让所有编排能力独立于开发和运维团队，任何一个团队都不应该将能力的具体操作保留在自己的团队中，采用声明式配置可以确保这一点，因为配置中只有声明没有具体逻辑，就意味着原来的依赖双方都必须将公用能力贡献出去，否则上图中的C就无法生效。

• 幂等性（Idempotence）：进一步来说，声明式配置必须能够在任何时候确保环境编排的结果，也意味着通用组件C中对于环境的操作必须能够在任何状态下执行并且获得一致的最终结果。换句话说，无论目标环境处于初始状态，中间状态，最终状态还是错误的状态，当加载声明式配置以后，都会变成我们需要的理想状态（Desired State）。

IaC的落地方法

从本质上来说，IaC是一种做事情的方法，实现IaC的方法和工具只要遵循以上原则，都可以帮助团队落地这种方法。在实际工作过程中，我们需要一些基本条件才能够实现IaC：

文化支撑

落地IaC将改变团队（特别是开发和运维团队）的工作模式和协作方式，双方的工作边界和职责都会发生变化。传统模式下，开发和运维团队通过流程进行协作，双方在需要对方配合的时候发起一个流程（发出请求），等待对方按照要求完成操作（给出响应）之后继续这个流程直到目标达成。而IaC则要求双方通过共享能力进行协作，双方需要持续发现协作中阻碍对方独立工作的问题点，一起将解决这些问题的能力贡献给另外一个双方共享的组件（一般是一个工具），在日常工作中不再依赖流程驱动对方，而是使用这个共享的组件（工具）完成工作。IaC的工作模式要求两个团队都接受不确定性思维方式，出现问题的时候要共同解决问题而不是界定和追究责任。如果团队中的文化不允许这种不确定思维方式的存在，IaC将无法落地。

共享工具

具备以上文化支撑的团队，需要共同构建一个双方都认可的工具，将双方都需要的环境编排能力全部封装到这个工具中。这个工具的核心目标有两个：

• 解耦：让双方在日常工作中不再依赖对方，可以按照自己的节奏和工作模式自由的使用，同时确保双方关注的标准，规则和策略都可以被正常落实并可以被监督。

• 可定制可演进：这个工具存在的目的就是为了能够适应不停变化市场需要，一个静态的工具是无法做到这一点的，只有那些具备了高度可定制性和扩展性的工具才有可能具备这样的能力。因此在设计和实现这个工具过程中做到功能粒度的控制就变得至关重要，如果所有的功能都按照日常业务流程设计，不考虑通用性，最终的结果就是任何的工作流程变更都会造成工具的变更，这样的工具也就失去了通用组件的存在价值。

IaC无处不在

实际上，云原生，微服务，容器化和DevOps都是在从各个不同的层面践行IaC。云原生强调利用云的基本特性赋能团队，其实就是利用上述云计算的底层技术为团队提供实现IaC的基础条件。微服务则是通过组件化的思维让多个团队可以独立自主的工作，不再受到其他团队的影响从而最大化团队工作效率。容器是在云计算技术的基础上，为操作系统以及其上层的环境堆栈提供IaC能力，包括Docker和Kubernetes为代表的主要容器工具都是基于声明式配置和幂等性原则设计的。

DevOps在这里又是什么呢？DevOps是以上所有这些概念，方法和实践的综合，实际上DevOps的范畴比这个还要宽泛。开头的那张图上你应该可以看到，从广度上来说，围绕Dev和Ops构成的这个无限环其实涵盖了软件交付过程的所有环节，从深度上来说，DevOps又可以涵盖文化理念、管理方法、商业创新、敏捷和精益、项目管理、团队管理、技术管理和工具实现的全部层次。以至于越来越多的人将越来越多的内容放在DevOps这顶帽子下面，出现了诸如：AIOps, GitOps, TestOps, DevSecOps, BizDevOps等很多扩展概念。

其实，我们不必纠结这个概念本身，因为来自于社区自发总结的DevOps本来就没有一个集中的知识产权所有者，也就没有人能够给予它一个明确的释义。这本身其实也是一件好事，因为就如同以上对IaC的分析解释一样，DevOps的存在也是在帮助我们持续改进的，如果它本身变成一个静态的方法集或者工具包，又如何能够适应当前不断多变的商业环境和市场需要呢？从这个角度来说，所有那些希望将DevOps进行标准化的所谓认证，体系和方案其实都是一种带有误导性的行为。

很多的企业在引入容器技术，微服务，云原生以及DevOps的过程中仍然在延续原有部门结构和工作流程，并且试图将这些新技术新方法融入到现有的流程中，而不是探索新技术新方法带来的全新可能性。我在过去十多年帮助企业实施落地DevOps的过程中遇到了太多类似的组织，其中最明显的表征就是你会发现那些推动DevOps实施落地的部门不停的界定责任，造锅甩锅，那么他们一定是在用DevOps耍流氓。以上我所描述的IaC的工作思路对这些人来说从来都不重要，他们不在乎问题出现以后的根源分析和改进措施，相反如果根源分析的结果让锅到了自己头上，那么宁可不分析；如果改进措施的结果是需要自己将一部分职能贡献出去，那更加不能做。最后的结果就是那个“共享工具” 里面埋藏了各种补丁，硬编码流程以及技术债务，可想而知这样的工具又如何能够承载不确定性，如何能够帮助其他部门提高效率，更不要提为组织提升总体效能了。对了，这个埋藏了大量定时炸弹的工具就是你们热衷的那个“一体化研发平台/DevOps平台”。

SmartMeetup(S01E05) - 10分钟搭建开源免费的私有CloudIDE服务

S01E04 - CLI使用详解 回顾

• Meetup 时间：2022.9.21 晚20:30 （临时调整在周三）
• 主持人：徐磊
• 观察员：衣明志，烟台易云网络创始人/资深.NET开发者/前微软最有价值专家MVP

在上周的Meetup上，我们邀请到了来自烟台易云网络创始人衣明志作为观察员参与我们的活动。我们对SmartIDE的核心模块CLI进行完整的介绍，为大家展示了以下场景：

• SmartIDE CLI 安装和基本操作
• 使用 start 指令在本地，远程主机和k8s集群上启动远程工作区
• 使用 host 指令将Linux主机注册为开发环境
• 使用 list/start/stop/remove 指令管理远程工作区生命周期
• 使用 new 指令从预制的开发环境模板启动新开发环境
• 使用 init 指令对现有代码库进行初始化，自动完成 IDE配置文件 的生成和适配
• 第三方系统集成：在 gitlab-ci 中集成smartide cli实现云原生IDE调度能力 下面是S01E04的视频回放，大家可以关注我们的B站频道

S01E05 - 搭建开源免费的私有CloudIDE环境

• Meetup 时间：2022.9.27 周二晚20:30
• 主持人：徐磊
• 观察员：周文洋，LEANSOFT研发总监/资深DevOps顾问/前微软最有价值专家MVP

本周二的 Meetup 我们邀请到来自 LEANSOFT的研发总监周文洋作为我们的观察员，周文洋曾经参与多家大型企业的DevOps实施咨询，也是《专业SCRUM - 基于Azure DevOps的敏捷实践》的主要译者，他的客户包括博时基金、浦发银行、华为等多家大型企业。

这次的 Meetup 我们将围绕 SmartIDE Server 这个产品组件展开，SmartIDE Server 是面向团队和企业的云原生容器化远程工作区管理平台，可以为开发团队提供统一的开发测试资源管理，基于浏览器的开发环境访问以及团队协作能力。SmartIDE Server 的 团队基础版 功能是开源而且免费的，任何人都可以按照本手册所提供的方式完成部署并免费使用，没有使用期限限制，没有用户数限制，也没有资源数量限制。

下图展示了 SmartIDE Server 的部署架构

下图展示了一个 SmartIDE Server 的云端工作区，同时支持使用多种方式进行连接

• VSCode WebIDE 浏览器接入
• JetBrains Gateway 远程接入
• 命令行终端直接接入

我们将现场完成以下场景的演示：

• 使用一台云端虚机完成 SmartIDE Server 的一键搭建过程
• 将Linux主机和Kubernetes集群注册到 SmartIDE Server
• 通过模版启动预置的开发环境
• 使用代码库URL启动项目开发
• 在Kubernetes工作区中嵌套运行 Docker 和 Kubernetes 进行云原生开发
• 在iPad上使用云端工作区

直播抽奖

一等奖：价值3500元的JetBrains全系列IDE激活码一个

二等奖：SmartIDE文化衫两件

立即扫码预约直播

HashiCrop和Forrester为企业云战略提供的4条建议

本文是译文，原文地址 https://www.hashicorp.com/blog/hashicorp-state-of-cloud-strategy-survey-2022-multi-cloud-is-working

有关 HashiCrop

HashiCorp是由Mitchell Hashimoto和Armon Dadgar联合创办，总部位于美国旧金山，致力于为企业提供服务，通过数据中心管理技术研发，让开发者通过工具构建完整的开发环境，提高开发效率。HashiCorp提供了大量的DevOps 基础设施自动化工具，集开发、运营和安全性于一体，可以帮助开发者编写和部署应用程序，加速应用程序分发，助力企业提升开发效率，包括：Vagrant、Packer 、 Terraform 、Serf 、Consul , Vault 和 Nomad 等。

2016年9月，HashiCorp 获得2400万美元的 B 轮融资，由GGV Capital 领投，Mayfield 、 True Ventures 和新投资方 Redpoint 参投。截至目前2016，该公司共融资3400万美元。2021年12月9日，美国云开源软件公司HashiCorp登陆纳斯达克，市值153亿美元，是迄今为止今年全球市值最高的开源IPO。

HashiCrop和Forrester通过调研得出的结论：90%的企业通过多云策略和专业的云平台团队取得成功；但安全、员工技能和费用管理仍然是非常大的挑战。– 《2022企业云策略现状调研报告》

第二份《企业云策略现状调研报告》已经发布，非常清晰的显示了以下结论：

• 更多的企业正在采用多云策略
• 组建专业的云平台团队对于企业的云策略取得成功至关重要

这些结论延续了我们2021年的首次调研的结论，今年的调研结果更加清晰的显示了多云战略，云安全性以及缺少专业技能正在影响着企业利用云计算的能力。2022年报告中的新发现是，专业的云平台团队正在组织中扮演越来越重要的角色，以及很多组织正在云平台的使用上浪费大量金钱。

我们在2022年的调研报告中引入了Forrester咨询作为调研机构，我们调查了超过1000个千人以上的大型组织的决策者和关键角色，这些被调研对象覆盖了全球的不同行业的组织。今年的报告 全文可以通过以下网址获取：

• https://www.hashicorp.com/state-of-the-cloud

您也可以扫码关注DevOps公众号，并输入：云策略报告2022，即可获取PDF版本的报告全文。

以下数据展示了本次报告中的关键结论，5个关键数据

• 90%的受访者认为多云战略可行
• 86%的受访者依赖云平台团队执行多云战略
• 94%的受访者认云资源使用中存在浪费
• 89%的受访者认为安全是决定云战略成功的关键因素
• 员工的云技能缺失是企业执行多云战略的最重要的障碍

云平台团队对执行多云战略非常有帮助

报告显示，81%的受访者正在使用多个云平台，或者计划在未来一年中采用这种策略。但这并不是真正的中带你。更重要的是，在这些采用了多云策略的组织中，90%的受访者认为这种多云战略已经对他们实现商业目标有所帮助。虽然我们的调研方法有所变化，但是相比于2021年的结果仍然是一个巨大的跃升，因为在2021年这个比例仅为53%。

多云战略之所以能够取得成功，与专业化云团队的增加很有关系，一般来说这些团队被称为 云平台团队 或者 云技术中心。受访对象中10家中有9家都有类似的职能存在，而在那些没有设置类似 职能的组织中，仅有四分之一在使用云而且他们并不认可云的价值。

这背后的原因应该是由于云团队为组织提供了很多关键能力。云团队的主要职能就包括：让云服务变得标准化，构建和共享最佳实践以及实现云安全/合规的集中管理。超过四分之三的受访对象依赖云团队完成被调研的全部15项职能。这些职能包含了非常多的关键能力，比如：构建云管能力和运维策略，开发和推广云最佳实践，构建云解决方案以及云运维操作。

安全、技能和费用管理仍然是重要挑战

当然，多云策略仍然充满挑战。90%的受访对象对于云安全非常担忧，并将安全列为第一优先级，甚至超过了可用性指标。下面一项关注点是员工的云技能短板，41%的受访者认为这是阻碍他们实现多云战略的关键障碍。正是因为云技能人才的紧缺，才使得 云平台团队 变得更加重要，因为这样企业可以最大化具备云技能的工程师的作用。

另外一个同等重要的挑战就是费用，仅有6%的受访对象认为他们的费用管理已经没有可提升的空间。剩下94%的受访者都被各种浪费所困扰，包括66%来自资源空转/无人使用，59%来自超规格部署以及47%来自员工技能缺失。从乐观的角度来看，仅有24%的受访对象在云费用上超支，因此至少大多数组织在云资源预算控制上做的还不错。

来自Forrester的关键建议

2022年的调研报告是HashiCrop和Forrester一同完成的，调研范围扩展到了HashiCrop的客户之外，并且提供了更加中立的分析和建议。你可以通过我们的报告官网下载完整版报告，以下列出了Forrester给予企业的一些关键建议。

• 为你的业务量身定制多云战略 - 多云战略有多种形式，Forrester建议企业管理者根据自己企业的情况考量哪种战略更加适合，并想清楚选择原因。
• 引入自动化对于减少浪费和提升效率非常重要 - 来自Forrester的建议：“引入自动化工具对于企业提升云资源利用率以及优化ROI（投入如产出比）非常有效。自动化不仅仅能够有效减少浪费，还能从整体上降本增效。”
• 充分利用自动化的安全工具来支撑多云战略 - Forrester 建议组织 “充分利用自动化工具不仅仅可以节省运维团队的时间，还能帮助解决非常复杂的IT问题，优化云资源成本，监测并消除安全隐患。”
• 构建全功能的云平台团队 - Forrester认为 “云平台团队可以帮助组织更好的推动多云战略的安全、管控、规范和框架、内部培训、云技能认证在整个企业的落地实施。” 同时也要意识到企业文化对于构建一个成功的云平台团队非常重要。

Meetup预告

本周二晚8点30分，SmartMeetup S01E05精彩继续，本期主题：搭建私有CloudIDE服务，扫码预约直播，千万别错过

现场还有抽奖

• 一等奖，价值3500元的JetBrains全系列激活码
• 二等奖，SmartIDE文化衫

SmartMeetup(S01E04) - 仅有50Mb的小工具搞定大厂才能玩的CloudIDE

Smart Meetup已经在上周二（2022.9.13）重新启动，后续我们将在每周二晚8点30分和大家见面。Smart Meetup得目标是持续为大家输出云原生IDE相关得最佳实践，并不局限于介绍SmartIDE自己的特性和功能，而是希望能够从软件工程的角度为开发者提供帮助。以下是我们当前规划的一些方向，希望各位小伙伴多提意见和建议：

• SmartIDE 特性介绍 - 按照我们的发版周期，每隔2周都会发布新版本给社区，我们会通过这个Meetup为大家介绍这些新特性，帮助大家尽快的将新功能用起来。
• 开源项目推荐 - SmartIDE的一个重要特点就是帮助开源社区的小伙伴快速的体验新项目，我们会继续这个做法，为大家喜欢的开源项目适配 IDE配置文件，并在Meetup为大家展示这些项目的能力。之前我们已经适配过的项目包括：若依项目、Gin-Vue-Admin和飞致云的Metersphere。
• 云原生相关技术分享 - 作为一款云原生IDE，SmartIDE不仅会利用云原生技术让开发者的工作变得更加简单高效，也同样在践行着各种云原生开发实践，比如我们之前就介绍过如何使用SmartIDE来开发调试Dapr应用。后续我们会继续这个方向的摸索，并将最棒的云原生开发实践推介给大家。
• 敏捷/精益/DevOps/研发效能相关实践和案例分享 - SmartIDE的定位是成为DevOps和开发者的桥梁，那么我们的Meetup也同样会承载类似的职责。我们会不定期的邀请行业内的专家大咖来给大家分享各种最佳实践和案例。

另外，在每一期的活动上我会邀请一位观察员，从用户的角度给予一些反馈，提出一些问题，帮助我们打磨产品，拓展使用场景。

S01E03 回顾

• 时间：2022.9.13 晚20:30
• 主持人：徐磊
• 观察员：施慧斌、FIT2CLOUD北区解决方案负责人

上周的Meetup距离之前的活动已经有了一段时间，因此我们首先对SmartIDE的一些进展给大家做了介绍，然后针对 Codespaces for Azure DevOps 插件进行了重点介绍。这次Meetup我们也邀请到了FIT2CLOUD北区解决方案负责人施慧斌作为观察员参与了整个演示。

CodeSpace for Azure DevOps 插件

SmartIDE产品定位于开发人员的的DevOps入口，基于这个定位我们在微软的DevOps平台Azure DevOps上进行了首次尝试。通过在Azure DevOps的电子看板，代码库，流水线和拉取请求的不同位置提供一键创建云端工作区的入口，为开发和测试人员提供快速稳定获取可用环境的入口。这个插件充分利用了SmartIDE的标准化环境编排能力，将原本静态的开发环境转变为随用随起，用完即焚的临时性环境，让原本很重的环境管理编程一键非常轻量而且便捷的事情。

对于用户而言，可以利用以上能力解决一些日常开发协作中的问题：

• 特性分支规范化： 特性分支是当前软件开发团队普遍使用的一种分支模型，要求开发人员根据不同的开发任务拉取独立的特性分支，并在这个分支上完成所对应任务的开发工作，起到聚合和隔离代码变更的作用。特性分支对于大型团队隔离不同特性之间的相互影响，做到灵活控制上线周期和发版方式来说效果非常明显。但是特性分支在企业落地中普遍存在几个问题：1）特性分支命令不规范，因为分支需要开发人员自己创建，经常会出现各种不规范的分支名称增高管理成本；2）代码夹带，很多开发人员认为特性分支操作太繁琐，经常会为了省事儿把多个特性在一个分支上一起开发，这样会造成后续发版过程中无法拆分清楚代码，造成未经审核的代码被夹带上线，严重的时候可能造成生产问题；3）操作流程复杂造成的误操作，特性分支要求开发团队具备非常严格的流程执行纪律，特性分支到发布分支再到主分支的合并过程不能随意跨越，但实际操作过程中很多团队并不能很好的执行这个流程，教育和培训成本都很高。这些问题的根源在于，git分支操作过于灵活并且可以在开发机本地完成，使得这个流程无法完全在线上闭环完成。使用云原生IDE之后，可是实现整个编码开发过程的线上化，不再依赖开发人员本地环境，实现完整的流程线上化闭环。
• 测试环境独立化： 测试环境的获取一直都是软件测试流程中的一个难题，受限于企业资源和自动化能力问题，大多数的开发团队仍然依赖开发人员手工部署测试环境。对于测试来说，最好能够给每个测试目标都提供独立测试环境，比如：手工测试应该针对每个测试人员的每个测试轮次提供，自动化测试应该针对每个被测版本的每个测试轮次提供。考虑上测试环境被测试用例污染的问题，还需要提供快速重置测试环境的能力。传统模式下，以上这些问题都没有特别好的解决方案，关键问题在于2个环境标准化能力不足（IaC实践没有被引入到开发测试阶段）和资源限制（容器化实践没有被引入到开发测试阶段）。使用云原生IDE，随用随起，用完即焚的环境调度能力可以有效解决标准化的问题，VMLC能力可以有效应对资源限制问题。开发环境独立化问题得到完美解决。
• 基于代码评审上下文的临时环境： 拉取请求时有效的代码评审机制，但是代码库所提供的拉取请求只能帮助评审者比较代码，无法帮助评审者从功能的角度验证代码的正确性。虽然CI/CD流水线中可以嵌入各种质量门禁，但是都无法让评审这从用户的角度了解应用行为的正确性。使用云原生IDE我们可以针对代码评审的上下文创建一个临时的让评审者可以直接进行操作，从用户的角度进行验证功能，辅助完成代码评审过程。

以下是本次Meetup的视频回访，Codespaces for Azure DevOps的演示部分在视频的43分钟开始。

另外，以下视频中也对这个插件进行了完整的演示和介绍

S01E04 预告 - CLI 详解

• 时间：2022.9.21 周三晚20:30 （本周特殊原因临时改在周三）
• 观察员：衣明志，烟台易云网络创始人/资深.NET开发者/前微软最有价值专家MVP
• 主题：SmartIDE CLI 详解

本周的Meetup将围绕SmartIDE的使用场景展开，CLI是SmartIDE产品架构中与其他类似产品最大的差异。大多数CloudIDE都会提供CLI工具，但是这些CLI都是作为辅助性工具存在的，也就是说用户使用CLI连接到CloudIDE服务来完成类似端口转发，如果脱离的CloudIDE服务，这些CLI本身是无法单独使用的。

SmartIDE的CLI则不同，用户可以使用CLI直接创建、停止，删除，清理远程/云端工作，这个过程无需CloudIDE服务（SmartIDE Server）的存在。

这样设计的目的是为了方便个人开发者可以非常轻量的管理自己的远程/云端工作区，无需预先部署Server。这样，个人开发者可以在需要的时候使用一个 smartide start 指令即可在任何资源上启动远程/云端工作。

从开发和调试的角度来说，CLI工具的迭代速度是带有WebUI或者API类型的应用无法比拟的。因为CLI极度简单的操作方式，我们无需处理界面的布局，美观，操作体验，各种边界条件等问题，可以专注于业务目标的实现。这种快速迭代能力让我们可以更早的触达用户，验证产品核心功能并及时调整产品方向。在过去的6个月，CLI的发布速度是平均每天3.8个版本。

CLI封装了管理远程/云端工作区的所有能力，这让用户利用CLI来搭建自己的CloudIDE系统，实际上SmartIDE Sever 本身就是这样工作的，通过将 CLI 打包成 tekton流水线任务，SmartIDE Server 的所有工作区操作都不会直接调用虚拟机或者k8s集群，而是通过CLI来完成。借助CLI的快速迭代特性，我们的Sever开发人员可以更加专注于用户体验和企业级功能，而不用关心底层工作区调度问题。 对于希望构建企业内部CloudIDE平台的组织来说，利用CLI的这种可集成特性，可以非常快速底层本的完整平台的搭建，不用去关注与虚拟机以及k8s集群进行操作的细节问题。

我们当前已经提供了gitlab-ci的集成示例，未来我们会提供更多各种类型的DevOps系统场景。

Meetup内容

本次Meetup将详细演示以下操作：

• SmartIDE CLI 安装和基本操作
• 使用 start 指令在本地，远程主机和k8s集群上启动远程工作区
• 使用 host 指令将Linux主机注册为开发环境
• 使用 list/start/stop/remove 指令管理远程工作区生命周期
• 使用 new 指令从预制的开发环境模板启动新开发环境
• 使用 init 指令对现有代码库进行初始化，自动完成 IDE配置文件 的生成和适配
• 使用 login/logout/connect 为Server工作区提供端口转发支持
• 辅助功能指令 config/version/reset/debug
• 第三方系统集成：在 gitlab-ci 中集成smartide cli实现云原生IDE调度能力

报名方式

扫描海报中的二维码通过B站直播间预约

直播抽奖

• 一等奖1名：JetBrains全系列产品激活码（价值1500元）
• 二等奖2名：SmartIDE 文化衫

市值200亿美金的Slack：远程开发如何提高开发效率

Slack简介：Slack 是聊天群组 + 大规模工具集成 + 文件整合 + 统一搜索。截至2014年底，Slack 已经整合了电子邮件、短信、Google Drives、Twitter、Trello、Asana、GitHub 等 65 种工具和服务，可以把各种碎片化的企业沟通和协作集中到一起。2014年初拿到了4000多万美元融资之后又完成1.2亿美元的融资。其估值也达到了 11.2 亿美元，这家公司成立仅仅 8 个月，这也使得它成为了有史以来发展最快的SaaS公司。2019年6月20日晚，创业公司Slack正式登陆纽交所。2020年市值一度突破200亿美金。

作者：Michael Deng, 在Slack平台部们任软件工程师。他已经在Slack工作超过3年时间（截至本文发布的2020年），在这个过程中，他曾经参与了各种类型的项目，包括用户界面，API基础设施以及增长性实验项目。 原文地址：https://slack.engineering/development-environments-at-slack/

译者：徐磊，开源云原生SmartIDE创始人、LEANOSFT创始人/首席架构师/CEO，微软最有价值专家MVP/微软区域技术总监Regional Director，华为云最有价值专家。从事软件工程咨询服务超过15年时间，为超过200家不同类型的企业提供过软件研发效能相关的管理和技术咨询工作。

原文地址：https://slack.engineering/development-environments-at-slack/

在本文中，开发环境特指那些用于在发布软件之前进行测试的环境，这个环境与集成开发环境（IDE）比如大家常用的Eclipse或者微软的Visual Studio不同，不是同一个环境。

开发环境对我来说一直都是一个谜团。虽然在加入Slack的第一天就学习过这个环境，而且之后每天都在使用它，但我从来都没有把这个环境是如何工作的搞明白。

大概半年前，我决定把这个开发环境彻底搞明白。于是我访谈了几位Slack最资深的工程师，阅读了大量的文档以及好多年积累下来的slack聊天记录。最终我发现，Slack所使用的开发环境其实经历了一个令人惊叹的发展过程。

为什么我们需要开发环境？

开发环境实际上是一个完整的Slack系统的副本，而且是一个允许我们随意进行修改的副本。这个环境的核心作用就是允许开发者可以在不影响真实用户，不会造成数据损失的情况下测试我们的改动。 这个环境对于我们进行快速迭代非常重要，而且允许我们将改动发送给同事进行评审。 总而言之，开发环境的存在大幅提高了我们的开发速度和安全性。

##工作机制

Slack的开发环境实际上是运行在远程服务器上的完整Slack系统，我们使用AWS的EC2服务器来承载这些资源。这些开发环境实例运行着完整的Slack系统，包括非常多的服务以及这些服务所依赖的其他资源（比如中间件）。 每个开发环境都有自己独立的slack二级域名，我们可以直接访问这些域名就可以通过浏览器查看我们的改动。 在开发环境里面的改动不会对真实用户造成影响，因为我们使用了隔离的基础设置，比如：与生产环境独立的数据库。

图：开发环境和生产环境是完全独立的而且隔离的。

本地开发 vs. 远程开发

在Slack，我们使用远程开发模式，意味着我们的开发环境全部位于远程服务器上。当然，另外的选项是使用自己本地的个人电脑作为开发环境，本地电脑对于小型项目很适合，因为速度快而且不需要联网就可以工作。但是对于大型项目来说，远程开发模式提供了非常多的好处。

• 第一，我们不需要在本地部署整个Slack系统。Slack的系统架构非常复杂，有大量的服务以及依赖，无需在本地配置这样复杂的系统对于我们来意义重大。
• 第二，如果我们的改动在开发环境工作正常，那么基本上可以确保在生产环境也可以工作正常。因为我们的开发环境在配置上尽量与生产环境保持一致。当然，如果开发环境实例运行了很久，那么它和生产环境就会有比较多的差异，但即便如此，相比让开发者使用自己本地的个人电脑所带来的各种差异而言，仍然可靠的多。
• 第三，远程开发环境不依赖个人电脑，而个人电脑经常会崩溃或者卡顿。云端资源性价比更高，更加可靠而且容易扩展。特别是，云端资源允许我们使用多台服务器进行开发，而且还可以非常容易的将改动共享给其他人。

总之，随着网络越来越快和稳定，远程开发模式越来越有优势。

Slack内部的日常开发流程

说明我们Slack内部工作流程的最佳方式是给大家展示一个示例。比如：因为某种原因，我们决定修改Slack主页的文字为全部大写的紫色Comic Sans字体。

为了完成这个任务，我们首先会创建一个特性分支（feature branch），然后使用 slack sync-dev 工具将分支和开发环境进行绑定。这个工具会随机选择一个可用的开发环境，并开始将本地的修改同步到这个环境，后续我们在本地所进行的任何改动都将自动同步到这个环境。

这个工具的底层其实使用了2个大家熟悉的工具，fswatch（检测修改）以及 rsync （同步修改）。

图：将改动同步到开发环境。

如果我们修改了前端页面，那么我们会在本地使用webpack进行构建和打包，然后运行 slack run build:watch ，这个指令会构建我们的前端资源并允许给我们通过 localhost 访问开发环境。 当我们完成开发，我们就可以直接访问上图中出现的 dev575 二级域名，我们改动就出现在远程开发环境中了。

图：右侧的首页就是我们的成果，是不是更加吸引人？

现在，我们就可以进行各种测试，调试甚至直接共享给其他人进行评审。

记住，到现在位置，我们仍然在使用我们构建的前端资源，如果我们希望在关闭个人电脑后仍然可以访问这些改动，那么就需要在开发环境中生成一个静态构建。

改进我们的命令行工具

让我们简单说一说这个命令行工具。在上面的实例中我已经展示了它的部分工具，就是 slack sync-dev 指令。这个工具对我们非常重要，因为它让我们的开发工具变得更快而且更加简单。

在没有这个工具之前，我们必须要手工同步改动到开发环境，这个过程非常繁琐而且容易出错。现在，我们不再需要手工操作60种不同的命令行工具，而只需要这一个工具就可以完成所有操作。

除此之外，我们还有 slack bot-me 指令，可以在开发环境自动创建一个机器人用户；以及 slack tail-dev 指令，可以将远程环境的日志同步到本地。如果你对Slack的内部工具该兴趣，可以参考我们2016发表的博客：构建内部工具是一件快乐的工作。

开发环境扩容历程

在2014年，我们只有一个开发环境，所有人都使用这一个开发环境。如果有人把环境搞坏了，其他人都只能停工。在当时，这并不是太严重的问题，但是随着slack变得越来越庞大，我们增加了越来越多的环境。到2019年底的时候，slack内部在同时维护550个开发环境，基本上每一个slack开发者都有自己独立的开发环境。

但是，这个于是并没有继续下去，实际上在2020年这个趋势被彻底扭转。在具体解释这个变化之前，让我先来展示以下这个图表：单个虚拟机所承载的开发环境数量。

这个数字在持续下降的原因是我们希望隔离每一个开发环境实例。因为当多个环境共享同一个虚拟机资源的时候，任何一个开发者所运行的复杂操作都会影响其他开发者的正常工作。

这带来一个副作用 - 当我们减少每个虚拟机所承载的环境数量的时候，我们就必须使用更多的虚拟机，这意味着更多的费用。同时，因为这些环境都需要被管理和维护，随着环境示例数量的增长，维护这些环境也带来了大量的开销。更糟糕的是，环境实例运行的时间越久，就越不稳定而且会积累大量和生产环境的差异，变得不适合使用。

为了解决这些问题，我们构建了一个可以动态按需初始化开发环境的系统。这个系统让上图中疯狂增长的环境数量得到了有效的控制。我们不再同时运行几百个开发环境示例，而是在需要的时候动态初始化一个给到开发者。而当开发者完成测试以后，这个实例就会被自动销毁掉。这个系统让我们可以更加高效的管理我们的开发环境。我们将在后续的博客中详细说明我们是如何做到的。

设计精良的开发环境对于任何一个科技企业的成功至关重要。在Slack，我们的开发环境，我们的工具和基础设施正在向着全面自动化和可扩展的方向发展。

开放原子开源峰会 - SmartIDE正式开源并发布v1.0版本

开放原子开源基金会是致力于推动全球开源事业发展的非营利机构，于 2020 年 6 月在北京成立，由 阿里巴巴、百度、华为、浪潮、360、腾讯、招商银行 等多家龙头科技企业联合发起。本次开源峰会是开放原子的年度品牌活动、全球开源领域的高端峰会。包括 工信部副部长王江平、北京市副市长靳伟、中国科学院院士梅宏，Linux基金会执行董事Jim Zemlin，Eclipse基金会执行董事Mike Milinkovich 以及来自阿里，腾讯，蚂蚁，华为，中软国际，英特尔等来自国内外的重磅嘉宾参与了本次会议。SmartIDE在本次峰会的云原生论坛上展示了项目当前的进展以及下一代云原生CloudIDE的使用场景。

产品开源地址：

• https://github.com/SmartIDE
• https://gitee.com/SmartIDE

彻底解决软件开发环境标准化问题

如今，软件确实已经深入我们生活的方方面面，没有软件你甚至无法点餐，无法购物，无法交水电费；我们生活的每一个环节都已经被软件包裹。在这些软件的背后是云计算，大数据和人工智能等各种高新科技；这些现代IT基础设施在过去的几年得了非常显著的发展，我们每个人都是这些高科技成果的受益者 … … 但是，提供这些高科技成果的 开发者们自己所使用的软件（开发工具）却仍然像 “刀耕火种” 一般落后。

你可能会觉得这是危言耸听，那么让我来举一个简单的例子：大家一定都通过微信给自己的朋友发送过图片，这个过程非常简单，拿出手机，拍照，打开微信点击发送图片，完成。收到图片的朋友直接打开就可以看到你拍摄的照片了。但是对于开发者来说，如果要将一份代码发给另外一位开发者，那么对方可能要用几个小时甚至几天的时间才能看到这份代码运行的样子。 作为普通人，你无法理解这是为什么，如果你是一名开发者，你一定知道我在说什么！

上面漫画中的场景是不是很熟悉？开发环境的搭建对于开发者来说理所当然的是要占用大量时间和精力的，但是对于 “产品经理/领导/老板” 来说，开始写代码就应该像打开Word写个文档一样简单，只有开发者自己知道这其实很不简单。当然，这件事情确实应该更简单，只不过开发者整天 忙着让别人的生活变得简单，却忽视了自己就的生活正在变得越来越复杂。

解决以上问题的终极方案就是云端工作区，从IDE产品本身的发展历程来看，在经历了超过30年的三代产品的发展演进后，主流IDE厂商都在向着云端工作区的方向发展。SmartIDE正是在这个大背景下应运而生的下一代IDE云端工作区管理工具。

用云原生技术赋能开发者

我们的使命是 用云原生技术赋能开发者，我们定位于“开源云原生CloudIDE”，希望将云原生中各种先进技术针对开发者的工作场景进行优化，让开发者也能享受云原生带来的好处。同时，针对现有CloudIDE存在的种种弊端，SmartIDE也会从开发者的诉求出发予以优化，比如：当前的CloudIDE大多数采用WebIDE+容器的技术基础来搭建，但是WebIDE本身有很多局限会影响开发者的体验和工作效率，比如：快捷键、多窗口、操作延迟等；针对这个问题，SmartIDE提供了Hybrid模式，允许开发者使用本地IDE（VSCode或者JetBrains）连接到云端工作区进行操作，让开发者既可以享受云端开发的强大又不需要改变自己的操作习惯。

容器技术虽然对于应用运维来说提供了很多优化，但是因为容器技术从一开始就是为了生产环境而设计的，并不适合直接用于承载开发调试环境。为了能够为开发者提供适合作为开发调测环境的容器，SmartIDE特别研发了VMLC（类虚拟机容器）容器，给予开发者在容器内极大的自由度，同时又可以确保对主机环境的安全保障。

在本次峰会的云原生论坛上，SmartIDE现场演示了以上两个场景。我们也会继续践行我们的使命，设计和开发一款真正为开发者解决问题、消除痛点、提高效率的开发者乐于使用的CloudIDE产品。

从新定义IDE

如果把Vscode和JetBrain这些IDE称为传统IDE的话，他们最大的问题是：虽然在 I (Integration) 和 D (Development) 上面传统IDE都做的非常不错，但是他们都没有解决 E (Environment) 的问题。

SmartIDE是 第一个提供完整环境标准化能力 的新一代IDE产品，拓展了传统IDE的的边界，对IDE的概念从新定义并且专注打造围绕这一全新IDE概念的开发者生态系统。加入开放原子基金会是SmartIDE继续拓展新一代开发者生态的重要里一步，我们将继续围绕开发者的体验重新定位现有的研发工具链体系，为个人开发者和企业提供一体化研发环境标准化解决方案，补齐传统IDE的短板。

SmartIDE可以完成开发环境的一键搭建，如果你熟悉命令行操作，那么安装我们的cli，只需要学会一个命令 smartide start 就可以一键完成任何项目的开发调测环境搭建，不再需要安装任何工具，SDK，调试器，编译器，环境变量等繁琐的操作。如果不喜欢命令行操作，也可以使用我们的 Server 通过网页完成全部操作。

SmartIDE提供了三种运行形态，针对个人开发者以及企业研发面临的不同场景，提供了简单方便一站式的开发调试环境解决方案。彻底解决环境（E）的问题。

• 本地模式： 面向 个人开发者 提供完整闭环的容器化开发调试环境调度，开发者可以在Windows/MacOS/Linux三种操作系统上使用 smartide start 指令一键启动任何开发语言的项目代码，直接进入调试状态，不必安装任何SDK以及开发工具。

• 远程主机模式： 面向 专业开发者和团队 的远程容器化工作区（云端工作区）启动模式，开发者可以将任何linux主机转变为一台全功能的CloudIDE服务器，使用同样的 smartide start 指令就可以完成远程服务器的管理和维护。对于需要使用云端服务器的强大算力、高速网络以及超大规模存储的人工智能，大数据，微服务开发场景，可以极大简化开发者管理远程开发环境的复杂度。

• k8s模式： 对于 企业团队开发 场景而言，能够将开发环境集中管理并标准化可以大幅减少开发团队花费在环境管理上的精力，同时提升 开发环境的安全性，稳定性以及开发效率。大型企业中使用标准化开发框架是普遍的实践，但是如何简单高效的推广这些开发框架是是一件非常困难的的事情，使用SmartIDE的k8s模式可以很好的解决这些问题。当前企业中已经有大量的k8s集群在使用，但绝大多数仅被用于测试和生产环境的管理，开发调测的环境在很多企业处于无管理或者疏于管理的状态，这为企业级研发来了大量的安全和稳定性隐患。SmartIDE k8s模式是针对企业级开发调测环境管理而设计的完整解决方案，为以上痛点提供了体系化的解决方案。

SmartIDE v1.0 已经发布

SmartIDE v1.0版本（CLI Build v1.0.23.4650，Server Build v1.0.23.4646）已经发布，在发布了超过4000 Builds 之后，我们终于发布了v1.0版本。当前的版本已经完成了 企业级云原生CloudIDE的特性闭环，允许 个人/团队/企业用户 在 Windows/Mac/Linux 上使用 VSCode/JetBrains全家桶/OpenSumi 三种IDE开发7种技术栈下的任何项目，并且支持WebIDE，Hybrid混合模式以及WebTerminal 的三种工作区访问方式。

SmartIDE产品体系包含 CLI，Server，开发者容器与模版以及插件市场四大组件，构成了企业级CloudIDE的完整生态环境。四大组件全部开源，为企业构建自主可控的私有化CloudIDE提供了一站式的解决方案。

个人开发者和企业用户可以从以下地址获取相关安装包、脚本和说明文档，立即开始体验：

• CLI 工具
  • 安装 https://smartide.cn/zh/docs/install/cli/
  • 快读启动教程 https://smartide.cn/zh/docs/quickstart/cli/
• Server
  • 安装 https://smartide.cn/zh/docs/install/server/
  • 快速启动教程 https://smartide.cn/zh/docs/quickstart/server/
• 开发者镜像和模版
  • 使用说明 https://smartide.cn/zh/docs/templates/
  • 开发者镜像和模版指令列表 https://smartide.cn/zh/docs/templates/#镜像和模版指令列表
  • 模版使用说明 https://smartide.cn/zh/docs/templates/#模版库
• 插件市场
  • 安装 https://smartide.cn/zh/docs/install/marketplace/
  • 配置IDE使用SmartIDE插件市场 https://smartide.cn/zh/docs/manual/marketplace/config/
  • 配置自动插件同步机制 https://smartide.cn/zh/docs/manual/marketplace/extension-sync/
  • 将你的插件发布到SmartIDE插件市场 https://smartide.cn/zh/docs/manual/marketplace/publish-extension/
  • 插件安装手册 https://smartide.cn/zh/docs/manual/marketplace/usage/
  • 使用自签名证书进行插件市场私有化部署 https://smartide.cn/zh/docs/manual/marketplace/self-signed-certificate/

我们也提供了多种开发语言技术栈的快速启动文档，方便开发者使用

• Node/前端开发 https://smartide.cn/zh/docs/quickstart/node/
• Java https://smartide.cn/zh/docs/quickstart/java/
• DotNet https://smartide.cn/zh/docs/quickstart/dotnet/
• Python Jupyter Notebook https://smartide.cn/zh/docs/quickstart/jupyter/

• CLI： 是一个使用go语言开发的简单易用的命令行工具，可以在Windows/MacOS/Linux三种操作系统上运行，同时支持x86和arm两种cpu架构。覆盖了当前几乎所有主流的桌面，笔记本，服务器，边缘服务，IoT设备和移动操作系统环境。为SmartIDE提供了在任何平台上进行CloudIDE管理和调度的能力。其关键特性包括：

  • 一键创建容器化工作区
  • 本地、远程主机、k8s三种模式支持
  • 自动创建SSH安全隧道，避免开放远程主机端口
  • 使用环境模版一键创建预制的环境和代码框架
  • 工作区状态管理登录SmartIDE Server实现远程端口监听
  • Headless运行模式，支持流水线集成（比如：在GitLab CI中利用cli创建云端工作区环境）

• Server： 采用vue.js + go语言开发的 开源企业级CloudIDE管理平台，支持单机和高可用两种部署模式，可以在隔离的企业环境内部署，支持多集群管理。主要特性包括：
  • 资源集中管控，支持纳管多台Linux主机或者k8s集群
  • 端到端的代码安全，实现研发过程全程代码不落地
  • 工作区入口，聚合所有研发资源
  • 环境模版，一键创建标准化开发环境
  • 团队管理，自由组合开发人员，按团队分配资源
  • 工作区策略、统一管理开发人员“本地”环境配置
  • 环境共享和协同开发

• 开发者镜像&模板： 一整套完整的容器化环境镜像和可扩展的模板系统，支持7类主流开发语言并可以扩展到任何开发语言和框架的支持。主要特性包括：
  • 加速工作区加载
  • 三种主流IDE支持，VSCode, JetBrains全家桶和阿里OpenSumi
  • 多种工作区接入方式：包括WebIDE、Hybrid混动、WebTerminal和Web文件管理器以及SSH直连
  • Hybrid混动模式同时支持 VSCode Remote和 JetBrains Gateway 两种接入模式
  • Rootless安全保障，使用非root用户运行容器内进程，避免容器越权
  • 支持在容器内运行嵌套完整Docker和Kubernetes集群（VMLC，Rootless安全模式），完美支持云原生开发场景

• IDE插件市场： 现代IDE需要使用大量插件扩展自身能力，在企业内部提供统一受控的插件市场有助于企业对开发调测环境、代码安全以及应用架构进行有效管控。我们基于Eclipse OpenVSX扩展开发了SmartIDE Marketplace，支持在隔离私有网络进行本地化部署并提供插件同步机制。主要特性包括：
  • 插件自动同步，使用预制脚本自动同步插件（包括历史版本）
  • 支持多种类VSCode IDE，比如：VSCodium, Code-Server, OpenVSCode Server，Eclipse Theia，OpenSumi

产品进展

SmartIDE的开发工作采用敏捷（Scrum&Kanban）方式进行，2周一个Sprint并且采用了高度自动化的流水线完成代码的构建，自动化测试和发布工作。到今天为止，我们已经完成了 超过4000个版本的发布，CLI每周下载量超过1000次。

过去的6个月中，我们完成了超过 400个特性的开发和交付，CLI完成了698次构建，Server完成了701次构建。

当前我们已经有来自几十家企业的超过200名早期使用者

开源进展

SmartIDE采用 GitHub和Gitee双地址开源 方式，并且支持社区开发者使用任何一个开源平台与我们的产品团队进行协作。为了满足开源社区协作和产品商业化开发同步推进的诉求，我们设计了 SmartIDE开源工作体系，帮助产品团队和社区开发者统一认知，高效协作。

具体可以参考：开源工作体系

在GitHub和Gitee有非常多的小伙伴与我们互动，收获了超过 500个star和80个Fork。同时也被gitee评选为 2022最有价值开源项目。

当前，SmartIDE已经进入 开放原子基金会项目捐赠的TOC审核阶段，我们认同并相信 “软件定义世界，开源共筑未来” 的理念，希望借助开放原子基金会的力量，继续扩大我们的社区影响力，吸引更多的共建单位一起构建开发者生态。以IDE这一软件开发基础软件为切入点，为更多的开发者和企业赋能，在开源开发者工作模式、企业级研发效能和信创领域打造世界级的下一代IDE工具平台。

欢迎更多的开发者和企业加入SmartIDE的开发协作，让我们一起做一个自己喜欢的工具。

徐磊 2022.7.29日于北京

埃隆马斯克五步工作法

开挂20年

截至2022年7月，埃隆马斯克（Elon Musk）个人财富为 2214亿 美金，他同时还是多家公司的CEO和创始人，包括：特斯拉，SpaceX，SolarCity，The Boring Company, Neualink 以及 OpenAI。但是大家恐怕没有注意到在马斯克众多的CEO头衔的后面，他也是特斯拉和SpaceX两家公司的首席工程师（Chief Engineer）。作为全球首富，这个首席工程师的头衔恐怕是绝无仅有的。实际上，马斯克确实是一位非常专业以及敬业的工程师，而他自己也更愿意被称为一名工程师而不是CEO。

如果看一下马斯克过去的20年，那绝对是开挂一样。2002年将PayPal卖给了eBay公司，个人获利1.8亿美金，如果你纳闷为什么这个叫做PayPal的产品这么值钱，那么我只需要告诉你支付宝的原型是PayPal，淘宝的原型是eBay，你就可以理解1.8亿美金其实一点都不多。如果现在让马云把支付宝卖掉，那绝对不只是这个数字。马斯克将这1.8亿美金全部投入到三家公司中，分别是：SpaceX（1亿美金），特斯拉（7000万美金） ，SolarCity（1000万美金）。2008年，SpaceX拿下美国国家航天局（NASA）价值16亿美元的大单，负责为国际空间站（ISS）提供货运飞船服务以及后续的载人航天任务。2021年，特斯拉所生产的 Model 3 轿车成为人类历史上销量最好的全电动汽车，总销量超过100万辆；同年，根据福布斯杂志的数据，埃隆马斯克成为世界首富。2022年，SpaceX成功实现了人类历史上第一家实现载人航天任务的私人公司，并且将三位亿万富翁送上了国际空间站，每人的火箭票价为5500万美金。在SpaceX之前，只有三个国家有能力将人类送入太空，分别是：中国、美国和俄罗斯。

在同样的时间线上，我们还可以看到另外一个经历了无数失败的马斯克。在SpaceX获得NASA的16亿美金订单之前，SpaceX已经炸毁了3枚火箭，准确的说猎鹰1号的前三次发射全部失败，这三次失败的发射已经几乎烧光了马斯克投入到SpaceX的1亿美金。在这个时间点，没有人相信马斯克的SpaceX可以成功发射火箭，因为在他之前，发射火箭这件事情一直被认为是只有国家这样的实体才能完成的任务。庆幸的是，2008年，猎鹰1号的第四次发射任务终于成功，也因此才有了NASA的订单，SpaceX才活了下来。即便如此，后续的SpaceX发射任务也不顺利，猎鹰9号火箭的首级回收经历了多次失败，而且在2015年最大一次事故中，整个火箭空中爆炸，价值600万美金的火箭和飞船全部报废。这个过程中，特斯拉的发展也不顺利，2009年就因为质量问题召回了345辆已经售出的Roadster，后续又出现了多起特斯拉自动驾驶事故将这个公司推入风口浪尖。而最大的挑战莫过于2017年特斯拉宣布推出 Model 3 车型以后经历的 “量产地狱”。马斯克在这一年的大多数时间都一直睡在特斯拉工厂的沙发和地板上，每天和工人一起解决生产线上出现的各种问题。Model 3的生产其实几乎让特斯拉到达破产的边缘，最严重的时候特斯拉距离破产只有几周的时间。

马斯克的5步工作法也诞生于这段时期马斯克自己对于 “量产地狱” 的亲身体验和经验总结。

五步工作法

下面这段视频来自 平民宇航员（everyday astronaut） 于2021年8月4日发布在Youtube上的一段采访，在采访中 everyday astronaut 的主播和马斯克一起参观了星舰（starship - 马斯克用来建立火星基地的飞船）的制造和发射基地。在参观过程中，马斯克突然回忆起自己在构建 Model 3 生产系统过程中的种种惨痛经历，总结了五步工作法并明确表示他正在全公司强力推广。

五步工作法并不复杂

1. 验证你的需求： 所有的需求都是假设，既然是需求，就是仍未实现的事情，你如何证明一个还不存在事物的正确性？ 马斯克特别强调了，在收到需求的时候一定要质疑，特别是那些来自专家的需求，因为你会不假思索的被对方的专业性所麻痹。但是任何人的专业性都来自他已经完成的事情，这种专业性只能说明他过去是对的，无法保障对未知事物的准确预测。

2. 最少的流程： 对于一个组织来说，如果没有觉得流程不够用，就说明流程已经太多了。 组织中存在流程是一件好事，但是如果所有的事情都有流程，那么组织中的个体就失去了创新和探索的能力，因此流程用于那些已经验证过的问题，无法应对未知的场景。当一个组织用既定的方式去应对不相匹配的全新问题的时候只有2种结果，1）流程会失效无法推进；2）按照既定流程做出错误的决策并造成不可预料的结果。无论哪种情况，最终受到伤害的都是组织本身。出现类似问题的时候，需要组织中个体站出来创造性的解决问题，只有这样组织才能充分适应未知的情况。当然这还必须依赖组织中鼓励创新的激励措施，有关于这一点马斯克也在很多场合提到过自己公司中是如何激励创新的。

3. 简化和优化： 所有的管理理论都在提简化和优化，但是 简化和优化的前提是目标的正确性（第一步）和鼓励创新的组织文化。 否则要么方向错误，要么找不到简化和优化的余地。“这个事情没有办法，流程就是这样”，这样的说法大家一定都听到过，其实这就是组织缺少创新激励文化的体现。

4. 加速迭代： 注意我们需要 加速的是迭代，而不是速度。 迭代是一个循环，通过这个循环我们可以不停的验证当前推进的方向，并且持续的进行改进和优化。因此，五步工作法不是一个单向一次性的行为，而应该在最小可执行粒度上持续的循环推进。 也意味着，你需要持续的质疑需求，持续的优化流程，持续的探索加速这个循环。这个过程的最终状态是组织进入一个自我推动，自我加速的状态，形成持续的创新和响应异常情况的能力，其实就是我们常说的敏捷性（agility）。

5. 自动化： 自动化水平恐怕是很多行业展示自身能力的一个特别吸引眼球的地方，相信大家所看到的大多数介绍特斯拉工厂的视频中展示的也都是高度自动化流水线，机器人以及空无一人的厂房。实际上，按照马斯克自己说法，他一直都希望特斯拉工厂中能够有更多的工人而不是全部都由机器人来工作。自动化的弊端有3个，分别是 1）高昂的成本；2）极高的出错几率；3）妨碍引入新特性。 实际上，特斯拉工厂中的工人数量大大多于其他汽车生产厂家，这其实也是马斯克有意为之。 一来是因为特斯拉汽车几乎所有的零部件都是自己生产/非外包的，这让特斯拉的工厂承载了几乎普通汽车厂家的整个产业链上工人的数量。其次，机器人/流水线都只能在非常严苛的固定条件下才能顺利工作，一旦出现异常，整条流水线都必须停下来等待问题的解决。这让整个流水线变成一个严重前后依赖的单线程系统，而马斯克真正希望构建的是一个可以随时更换组件、流程、探索新特性的并行系统。

特斯拉如何像造软件一样造汽车

这里不得不说明一下特斯拉革命性的汽车生产流水线，和传统汽车厂的流水线相比较有非常大的不同。并不是说特斯拉的生产线使用了更多的自动化机器人，而是特斯拉的生产线可以随时引入新特性，新部件和新的生产工序；这个特性 非常像在互联网软件开发中所使用的灰度发布方式。 相对而言，传统车厂的流水线只能重复生产同样的型号汽车，不具备随时更换配件，工序以及引入新型号的能力。

为了做到这种高度灵活的生产流水线，特斯拉做到了3点传统车厂望尘莫及的事情：1）高度模块化的车辆设计；2）生产中测试的能力；3）灰度制造流水线。

1）高度模块化的车辆设计

首先，特斯拉的车辆设计是高度模块化的，每个模块之间用明确的接口定义（API）来进行对接，这种设计模式让特斯拉可以围绕车辆形成多个独立工作又可以相互协作的小型团队（Scrum团队）。

来源: Agile Hardware https://www.youtube.com/watch?v=_rySu6FZ18c (2021.3.30)

2）生产中测试的能力

其次，生产中测试的能力（Test in Production） 是特斯拉能够实现高度自动化流水线，同时允许引入新特性的重要前提。在以上模块的基础上，特斯拉开发了可以在生产线上执行并验证的大量自动化测试，这些测试不需要等到车辆下线以后再执行，而可以在车辆的装配过程中随时执行。这些大量的自动化测试所构建的Test in Production能力，让特斯拉可以放心的随意更换车辆组件，同时确保最终的产品质量。

有了模块化和自动化测试得保障，特斯拉可以放心大胆得实施自动化，并且可以随时引入新功能，新组件。

" Humans are for creative problem solving, automation is for EVERYTHING ELSE."

" 人的作用是创造性的解决问题，剩下的所有重复性工作交给 自动化。

3）灰度制造流水线

有了以上模组化的架构和在生产中测试的能力，特斯拉可以实现以下的 Agile NPI（新产品引入） 能力。这整个的过程非常像互联网公司的软件灰度发布过程，比如你会看到APP中所显示的商品价格和其他人不同，或者你能够尝试一些新的功能而其他人还看不到。类似这样的产品发布方式称之为灰度发布。特斯拉在的汽车（硬件）生产线上实现了类似的能力，这个过程简单来说有这样几个步骤：

• 在某个生产工序之前和之后各安装一个路由器，注意这个路由器上运送的是组装中的汽车
• 当特斯拉的某个组件团队（Scrum团队）需要尝试安装新组件的时候，会通过以上路由器从主线上提取一辆汽车作为实验品（fork a car - 类似于软件开发中拉代码分支的过程）
• 这个组件团队在这辆实验品汽车上安装新的零件，同时确保这个新安装的组件可以通过和主线一样的质量验证步骤；这里涉及两个重要的措施，DoR(Definition of Ready 就绪标准) 和 DoD(Definition of Done 完成标准)。就绪标准和完成标准，一前一后，利用前面提到的生产中测试的能力，确保进入工序和离开工序的试验品车辆的质量。
• 通过了质量验证的实验品车辆合并回到主线，于其他车辆一同下线并直接发送到最终用户手中

具备了 Agile NPI 能力的特斯拉生产线，每一辆下线的汽车都可以是不一样的。特斯来对于已经发售汽车的跟踪方式也和传统车企不同，传统车企一般会用年度型号来标识汽车的类型，比如：2021款，2022款，每一个款型的配置是一样的；但是特斯拉的每辆汽车都是被独立跟踪的，因为每辆汽车的零部件和程序可能都是不同的。下图中可以看到，特斯拉可以 每周推出多达27项 产品改进，而传统车厂需要 2.5-4年的时间才能推出一款新车。

简单粗暴的计算一下，特斯拉的创新速度是传统车企的 27 * 52 * 2.5 = 3510倍。

这其实就是为什么传统车厂会处于绝对的劣势，因为特斯拉已经将敏捷能力根治于生产系统中，采用的是和造软件类似的方式，而传统车企还在使用100年前福特T型车的古老生产方式。当然，构建这样的生产系统是一件非常复杂而且困难的事情。

马斯克自己说过：构建特斯拉生产线的难度高于设计特斯拉汽车100倍。

2017年的多数时间，马斯克都住在特斯拉的加州工厂中和工人一起改进这个生产线。以下这段视频中马斯克讲述了这个过程中的一个优化点，你无法想象从生产环节中删除一个小小的玻璃纤维垫竟然可以节省超过200万美元的生产制造成本。

敏捷思维方法

以上出现了很多大家可能并不熟悉的词汇，比如：Scrum, DoR, DoD等等。其实这些概念都来自于敏捷思维方法。实际上马斯克的五步工作法就是典型的敏捷思维体现，其中前3个步骤解决的是 做正确的事 的问题，后3个步骤解决的是 正确的做事 的问题，中间的第三步是衔接前后的关键，也是 形成组织敏捷性（agility）或者自驱力 的关键。

如果用最浅显的语言来解释敏捷，那就是：一切都在变化，不变应万变的唯一方式就是响应变化。

虽然敏捷思维来自西方（敏捷的准确定义来自 The Agile Mainfesto 敏捷宣言 )，但其实中国文化中一直都存在类似的说法和思维模式，比如：天下武功唯快不破，这里的快指的的就是敏捷。当然，这里的快所指的并不是速度快，而是反应快。这一点我相信看过武侠小说的小伙伴都能理解。真正的高手从来不会拘泥于某种招式，兵器或者套路，而是见招拆招，手中无剑胜似有剑。这其中的境界其实就是可以应对世间万物风云变化，我自岿然不动的唯一方式：敏捷。

黄金圈理论

黄金圈理论（The Golden Circle） 是管理大师西蒙斯涅克2010年在一段TED演讲中提出的，其核心思想是希望大家在关注事物的时候多关注背后的 WHY 而不要只看到外部的 WHAT。实际上马斯克的五步工作法也可以用黄金圈来进行解释，其中第一步就是在回答 WHY 的问题，为什么我们要这么做，这个需求到底是为了解决什么问题？然后，我们再来回答如何满足这个需求的问题（HOW），用最少的流程和持续的改进以最快的速度找到当前的最优解。方向正确以后再提出明确的任务（WHAT）并以最快的速度完成这些任务。

马斯克用五步工作法构建了 一种持续的WHY-HOW-WHAT的迭代循环，推动企业内部形成一种高效的创新文化。这其实就是为什么马斯克所创办的企业能够在这么短的时间内创造出这么多令人惊叹的成果的原因。

马斯克曾经在自己的Twitter上写过这样一段话：

“Pace of innovation is all that matters in the long run！”

我会把它翻译成

“长跑冠军的秘诀从来都不是速度、而是配速！”。

相信热爱跑步的小伙伴一定知道我在说什么。

徐磊

2022年7月8日 于北京

参考资料

• Insights of Agile at Tesla with Joe Justice
• How Elon Musk plans to occupy Mars, the agile way
• Joe Justice | The Secrets to Agility at Tesla | Elon’s Master Plan to Infinity
• Model 3 production hell
• Evidence that Musk is the Chief Engineer of SpaceX
• Tesla Model 3 Has Passed 1 Million Sales
• Model 3 Wikipedia Page
• The 5 Failures of Elon Musk and How He Overcame Them

【开源云原生大会】现场演示：k8s套娃开发调试dapr应用

k8s集群套娃（嵌套）是指在一个k8s的pod中运行另外一个k8s集群，这想法看上去很疯狂，其实这想法也非常实用。 试想，当你开发一个k8s应用的时候候一定会希望在自己的环境中先测试一下，这时你有几个选择：1）自己找服务器搭建一个完整的集群；2）在自己的本地开发机中搭建一个精简的集群，比如使用minikube或者docker desktop；3）直接在生产环境部署。无论哪种做法，你都需要面临很多难以解决的问题，自己搭建完整集群操作复杂而且还需要额外准备服务器资源，本地搭建集群对开发机要求高，没有个8核16G的高配笔记本是不可能的，更不要说minikube和docker desktop 只支持单一节点的阉割版集群，做简单的测试可以，如果要完成一些复杂的集群调度实验就会显得力不从心。最后，如果你打算直接在生产环境部署，那么需要足够的胆量并且随时做好怕路的准备。

其实，这是当前云原生开发的一个普遍困境，开发环境变得越来越复杂，以往我们只需要拿到源代码就可以开发调试的日子不再有了。k8s环境使用起来方便，但是对于开发者而言，要获取一个用户开发调试和测试，或者随便可以折腾的环境太困难了。今天要给大家介绍的k8s套娃就是为了应对这个困境的，让开发者可以实现 随用随启、用完即焚！

云原生IDE的优势和困境

云原生开发的最佳环境其实就是云原生环境本身，既然我们的应用会运行在容器中，那么我们为什么不直接到容器中开发；既然我们的应用会运行在K8s中，为什么我们不直接在k8s中进行开发？先不用关心如何实现，我们先来看看这样做会带来怎样一些好处：

• 适用于任何人、任何时间、任何地点的标准化环境：将开发环境放入容器意味着我们可以像管理容器一样管理开发环境，类似系统配置、开发语言SDK，IDE，测试工具，配置项等等都可以利用容器技术进行标准化；同时因为是容器，我们可以实现 Lift & Shift （拿起就走&插上就干活）的能力。你只需要对开发环境定义一次，就可以让任何人在任何地方复制出同样的环境。

• 彻底消除项目上手和切换成本：基于以上能力，我们将开发环境配置文件也放入当前项目的代码库，开发者只要拿到了代码就拿到了环境（因为环境配置文件和代码版本是统一管理，版本保持对齐）。这样开发者再也不用为了调试某份代码重新搭建环境，可以随时随地的切换到应用的任何版本上，甚至可以同时开发调试一个应用的不同版本。这其实就 IDE as Code 的概念体现，具体请参考 这篇博客。

• 端到端的代码安全：既然开发环境位于容器中，我们就可以将这个容器放置于一个完全受管控的云端环境中，项目的代码完全在这个容器中被处理，开发者不需要下载代码；所有的代码操作，包括：编写，编译，打包，测试和发布过程全部通过网页在云端完成。对于需要很高代码安全性保障的行业，比如：金融、军工、通讯和高科技企业来说；这个特性可以彻底解决代码安全问题。而且，使用云原生IDE还可以在保障代码安全同时允许企业放心的使用外包开发人员。在当全球疫情持续发展的情况下，远程开发基础设施变成了企业的必备能力，云原生IDE在这方面有天然的优势。

• 解锁云端超算力环境：很多大规模系统动辄需要几百个服务组件才能运行，要在本地完成这种环境搭建是完全不可能实现的，即便有专业运维团队的支持，在云端复制类似的环境也困难重重，这造成在很多大规模开发团队中，开发/调试/测试环境的获取变成了一个普遍的瓶颈。而利用云原生IDE所提供的IDE as Code能力，复制一个环境和启动一个普通的开发环境没有本质上的区别，开发者在代码库中随意选取一个代码版本一键完成整个环境的搭建变得非常简单。测试环境的获取能力是评估一个团队DevOps能力的通用标准，采用基于 IDE as Code 的之后，获取这项能力的门槛将被完全抹平。开发人员也因此可以完全解锁云端的超强算力，存储和高速网络环境，对于AI，大数据，区块链，Web3.0这些需要复杂环境支撑的开发场景，云原DE更加是一个必须品。

当然，云原生IDE也并不是没有缺点，使用容器作为开发环境本身就会遇到很多的问题。

容器化开发环境的困境和解决方案VMLC

容器化技术出现以后，绝大多数的使用场景都是生产环境，因此对容器的优化目标都是围绕精简，单一进程，不可变状态的目标来实现的；对于开发人员来说，按这种目标设计的容器并不适合作为开发环境来使用。相对于生产环境中已经预先确定的配置，开发环境的配置则需要进行持续的调整，在Inner Cycle中，每个环节（包含了编码，编译打包，部署，测试，修复）都会产生环境变更的诉求。

VMLC（类虚拟机容器） 是 VM Like Container 的缩写，其设计目标是为开发者在容器中提供类似虚拟机的环境，包括：systemd服务管理能力，sshd远程登录能力，docker/k8s嵌套能力等。

使用VMLC技术实现容器嵌套

SmartIDE 是完全基于 IDE as Code 理念设计和开发的一款 云原生IDE 产品，开发者既可以使用 SmartIDE CLI 在个人开发环境中一键拉起 云原生IDE 开发环境，也可以由企业管理员部署 SmartIDE Sever 统一管理。SmartIDE 支持跨平台,Windows / MacOS / Linux 均可以使用，开发者也可以选择自己习惯的 IDE工具，比如：VSCode, JetBrains全家桶 以及 国产开源的OpenSumi。 SmartIDE 通过 开发者镜像和模版 同时支持7种主流开发语言技术栈，包括：前端/Node/JavaScript, Java, DotNet/C#, Python/Anaconda, PHP, Golang, C/C++；如果这些内置的镜像和模版都无法满足开发者的需求，也可以通过定制的Dockerfile和模版定义来进行扩展，这些 Dockefile和模版 全部都采用GPL3.0开源协议免费提供给社区使用。

以下演示是在 2022年6月11日举办的 开源云原生开发者大会 上的展示的使用 SmartIDE VMLC开发者容器 完成一个 dapr 应用的开发调试场景：

以下是视频中演示的操作手册，感兴趣的小伙伴可以自己操作体验一下；示例采用 dapr-traffic-control 应用代码，代码库地址如下：

• https://github.com/SmartIDE/sample-dapr-traffic-control

所有操作脚本都可以在以上代码库中找到。

创建支持VMLC的AKS集群

使用以下脚本创建 Azure Kubernetes Service

如果没有安装 Azure CLI 命令行（az 指令）工具，可以通过这个地址安装 https://docs.microsoft.com/zh-cn/cli/azure/install-azure-cli

## 以下脚本可以在Windows/MacOS/Linux上运行

## 创建aks
## 登录并切换到你需要使用的订阅
az login 
az account set -s <订阅ID>

## 创建资源组，资源组可以方便你管理Azure种的资源，后续我们可以直接删除这个资源组就可以清理所有资源
az group create --name SmartIDE-DEMO-RG --location southeastasia
## 创建一个单节点的AKS集群，使用 Standard_B8ms 节点大小，可以根据需要修改脚本
az aks create -g SmartIDE-DEMO-RG -n SmartIDEAKS --location southeastasia --node-vm-size Standard_B8ms --node-count 1 --disable-rbac --generate-ssh-keys
## 获取链接密钥，密钥文件可以自动保存到当前用户的默认位置 ~/.kube/config 
## 获取后本地可以直接私用 kubectl 操作集群
az aks get-credentials -g SmartIDE-DEMO-RG -n SmartIDEAKS

完成以上操作后，我们就获取到了一个可用的AKS集群，整个操作不超过5分钟；下面使用k9s连接到集群进行状态监控，k9s是一个基于命令行的可视化k8s管理工具（Windows/MacOS/Linux都可以使用），非常方便而且轻量，安装地址如下：

• https://k9scli.io/

激活VMLC支持

VMLC容器需要底层容器运行时的支持，以下指令可以完成sysbox container runtime的安装

有关sysbox的详细信息可以参考 https://github.com/nestybox/sysbox

## 获取节点名称
kubectl get nodes
## 在节点上添加 sysbox-install=yes 的 label
kubectl label nodes <节点名称> sysbox-install=yes
## 安装 sysbox container runtime
### 国内安装地址
kubectl apply -f https://gitee.com/smartide/SmartIDE/raw/main/deployment/k8s/sysbox-install.yaml
### 国际安装地址
kubectl apply -f https://raw.githubusercontent.com/SmartIDE/SmartIDE/main/deployment/k8s/sysbox-install.yaml

执行后可以在k9s中实时查看安装进度，等待以下这个安装进程结束即可开始使用。

部署sysbox container runtime是集群级别的一次性操作，只需要管理员在创建集群的时候执行一次即可。

部署VMLC开发环境

所有VMLC开发环境均通过开发者镜像的方式提供，在 smartide-dapr-traffic-control 这个代码库已经放置了适配好的 VMLC开发环境部署 manifest 文件，文件内容如下：

apiVersion: v1
kind: Pod
metadata:
  name: smartide-dev-container
  annotations:
    io.kubernetes.cri-o.userns-mode: "auto:size=65536"
spec:
  runtimeClassName: sysbox-runc
  containers:
  - name: smartide-dev-container
    image: registry.cn-hangzhou.aliyuncs.com/smartide/smartide-dotnet-v2-vmlc
    command: ["/sbin/init"]
  restartPolicy: Never

使用以下脚本即可获取源码并完成 VMLC开发环境部署

git clone https://github.com/SmartIDE/sample-dapr-traffic-control.git
cd sample-dapr-traffic-control
kubectl apply -f vmlc/smartide-vscode-v2-vmlc.yaml

执行以上操作以后，通过k9s查看名为 smartide-dev-containter 的 pod 的部署状态，部署状态为 running 即可开始使用了。

执行以下指令进入 smartide-dev-container 容器

kubectl exec -i -t -n default smartide-dev-container -c smartide-dev-container "--" sh -c "clear; (bash || ash || sh )"

现在我们就可以在这个运行在 k8s 集群 pod 的容器内进行操作了

## 切换到 smartide 用户
su smartide
## 切换到 smartide 的默认目录
cd
## 将 smartide-dapr-traffic-control 代码克隆到容器中
git clone https://github.com/SmartIDE/sample-dapr-traffic-control.git

在VMLC容器中内置一个叫做 smartide 的普通用户，这是一个非 root 用户，默认情况下VMLC容器全部通过这个用户进行操作，避免越权访问主机资源。 这个容器中已经内置了dotnet开发环境以及dapr cli工具，但是使用 terminal 操作确实不太方便。下面让我们切换到 VSCode WebIDE 进行后续的开发工作。

使用VSCode WebIDE访问VMLC开发环境

在SmartIDE所提供的VMLC开发者镜像中已经内置了 VSCode WebIDE，下面让我们将容器的3000端口映射到本地的6800端口，并通过浏览器访问我们的VMLC开发环境。

## 在你本地开发机的另外一个terminal中运行以下指令
## 注意不要使用以上已经进入 dev-container 容器的terminal
## 这个指令会将远程k8s pod中容器的3000端口映射到你本地的6800端口
kubectl port-forward smartide-dev-container 6800:3000

现在，你就可以打开 http://localhost:6800 端口并访问内置于 VMLC 容器中的 VSCode WebIDE 了，点击 Open Folder 按钮，并打开 /home/smartide/sample-dapr-traffic-control 作为我们的工作目录

点击 OK 之后，你就可以开始愉快的编码了，注意你现在使用的是 smartide 用户访问 smartide-dev-container 的开发环境

通过VMLC的开发者镜像，我们已经在这个环境中内置了 dotnet sdk， 以及 dapr cli, kubectl, helm，docker 等常用云原生开发工具。你可以按照 这篇博客 的操作完成这个dapr应用的 self-hosted 模式的开发调试。这个模式其实是将容器作为你的本地开发环境，并通过容器中的docker嵌套支持来提供 dapr所需要的中间件环境。

你会发现使用WebIDE进行类似的操作非常方便，这同时也意味着你已经脱离了你本地的开发机，可以在任何地点访问这个位于云端的开发环境。 当然，如果你不习惯在浏览器中操作IDE环境，也可以通过你本地的常用IDE来访问我们的远端 VMLC开发环境。

使用Hybird模式访问云端工作区

在 SmartIDE VMLC 开发环境中，除了内置 WebIDE 之外，也内置了 ssh 服务。也就是说，你现在可以像访问一台普通的云端虚拟机一样访问你的 VMLC 容器开发环境。 运行以下指令将 VMLC 的22端口映射到本地的 22002 端口上

kubectl port-forward smartide-dev-container 22002:22

现在你就可以打开本地的命令行通过标准的SSH协议访问这个 VMLC 开发环境了。

## 使用以下指令建立SSH连接，默认密码 smartide123.@IDE (这个密码可以通过后续的SmartIDE CLI或者Server进行重置）
ssh smartide@localhost -p 22002

当然，通过命令行的方式并不是每个开发者都习惯的方式，那么我们可以通过 VSCode 的 Remote SSH 插件或者 JetBrains Gateway 所提供的SSH通道连接方式，将你本地的VSCode或者JetBrains IDE连接到这个远程的 VMLC云端云端工作。这个就是 Hybird（混动）模式。

Hybird 模式兼顾了本地IDE和云端工作区双方的优势，让开发者在编码的过程中既可以享有本地工具的快速跟手的操作体验，又可以方便使用云端的超级算力。

VSCode Remote SSH 连接

在VSCode中连接云端工作区非常简单，你只需要在 SSH Remote 插件中点击添加连接，然后输入以上 SSH连接指令即可，这个过程与使用SSH连接一台远程主机完全一致。如果你看不到这个远程连接工具链，那么请从 这里安装 SSH Remote 插件 即可。

连接以后，设置工作区到 /home/smartide/sample-dapr-traffic-control 目录，即可看到如下界面。

JetBrains Gateway 连接

启动Gateway之后，选择 New Connection，并按我们的SSH指令填写信息，并点击 Check Connection and Continue 按钮

这时Gateway会要求你输入SSH登录密码，输入之后会进入以下IDE类型选择界面，根据需要选择你希望使用的IDE，因为dapr是一个基于dotnet 6.0的项目，我们在这里选择Rider作为我们的接入客户端IDE。

然后制定工作区目录为 /home/smartide/sample-dapr-traffic-control 目录，点击 Download and Start IDE。这时Gateway会自动在远程工作区启动 Rider IDE Server，并在本地启动 JetBrains Client，通过我们设定的SSH通道连接

启动完成的运行 JetBrains Client 如下

现在，我们已经完成本地IDE和远程工作区之间的Hybird模式连接。开发者可以根据自己的喜好和操作习惯选择使用WebIDE或者Hybird模式连接到基于VMLC的远程工作区。WebIDE的优点在于随时随地轻量编程，对本地开发机基本没有任何资源压力，即使使用一台ipad也可以完成开发工作；而Hybird模式的优势在于编码体验（特别在一些复杂的键盘操作和窗口布局控制上），特别是重度IDE用户会面对非常复杂的大规模项目，这种项目要完全运行在本地开发机是不可能的。

以下操作使用VSCode Remote SSH模式完成。

在容器中创建k8s集群

下面，让我们来将这个应用部署到 容器中嵌套的k8s集群 中。首先执行以下指令，使用kind创建一个多节点的k8s集群。

备注：Kind (Kuberentes in Docker) 是k8s开源项目下的一个sig，项目地址 https://kind.sigs.k8s.io/，希望了解KIND详细背景和使用方法的小伙伴可以自行参考

cd vmlc
kind create cluster \
    --config multi-node.yaml \
    --image registry.cn-hangzhou.aliyuncs.com/smartide/nestybox-kindestnode:v1.20.7

以上指令执行完毕后，我们可以在容器中运行k9s指令，实时查看容器内运行的集群状态，如下图可以看到2个节点已经处于Ready状态

编译打包并部署dapr应用到k8s集群

现在我们可以进入 src/k8s 目录执行 build-docker-images.ps1 脚本，这个脚本会完成所有应用的docker images的构建。

cd src/k8s
pwsh build-docker-images.ps1

现在我们来登录到 docker hub 并将打包好的 images 推送上去（这个步骤你在执行时可以跳过，所有镜像已经推送并设置为公开模式，可以直接拉取使用）。

docker login
pwsh push-docker-images.ps1

最后，我们使用以下脚本在k8s集群上部署dapr基础服务和示例应用的服务。

## 在默认的k8s集群中部署dapr基础服务
dapr init -k
## 部署 dapr-traffic-control 应用
pwsh start.ps1

下图：dapr基础服务启动中

下图：dapr-traffic-control 相关服务启动中

至此，我们就完成了k8s套娃旅程。如果我们不再需要这个环境，就可以通过以下指令一键清理掉这个 VMLC 环境，其中的所有内容也就从我们的集群上彻底清除了。

kubectl delete -f vmlc/smartide-vscode-v2-vmlc.yaml

这个过程中，大家应该可以明显体会到使用套娃方式运行K8s集群的好处，那就是简单轻量，节省资源。当然这个过程中容器的安全也是得到充分保障的，VMLC内部使用时非root账号，开发者在容器内无论进行怎样的操作都不会对所在集群的底层节点资源造成影响，是完全隔离的rootless环境。

使用SmartIDE一键启动VMLC环境

当然，以上操作过程中大家也会有另外一个直观感受，就是太复杂。完成类似的操作需要开发者对容器，k8s以及网络有充分的了解；这对普通开发者来说过于复杂。 SmartIDE的设计出发点就在这里，让开发者可以在 不学习/不了解 云原生技术的前提下享受云原生技术带来的好处。在刚刚结束的 SmartIDE Sprint19中，我们已经发布了 Server版私有部署手册，开发者可以使用一台linux主机就可以自行部署一套完整的SmartIDE Server环境，并用它来管理自己的云端工作区。

特别说明：SmartIDE Server的基础版功能是开源免费的，任何人和企业都可以免费获取并无限量使用。

使用SmartIDE Server云端工作区启动一个工作区就会变得非常简单，开发者复制Git仓库地址粘贴到如下界面，即可启动一个远程工作区；这个远程工作区可以运行在远程主机或者k8s环境中，对于很多开发者而言，K8s仍然是一个过于复杂的存在，但是几台云端的linux主机已经基本上是每个开发者的标配了。现在，你可以将这些Linux主机资源利用起来，使用 SmartIDE Server 将他们转换为高效的云端开发工作区。

下图：使用SmartIDE Server创建云端工作区

下图：运行在SmartIDE Server中的基于VMLC的远程工作区，正在部署dapr基础服务的状态

最后，希望每一名开发者都能寻找到云原生时代的原力；May the force with YOU!

社区早鸟计划

如果你对云原生开发环境感兴趣，请扫描以下二维码加入我们的 SmartIDE社区早鸟计划

谢谢您对SmartIDE的关注，让我们一起成为云原生时代的 Smart开发者, 享受 开发从未如此简单 的快乐。

让我们一起成为 Smart开发者，享受开发如此简单的乐趣。

为什么Dapr是比SpringCloud和Istio更优雅的微服务框架？

Dapr 是微软主导的云原生开源项目，2019年10月首次发布，到正式发布 V1.0 版本的不到一年的时间内，github star 数达到了 1.2万（现在已经超过1.7万星），超过同期的 kubernetes、istio、knative 等，发展势头迅猛，业界关注度非常高。

Dapr 这个词是是 「Distributed Application runtime」的首字母缩写，非常精炼的解释了 dapr 是什么：dapr 是一个为应用提供分布式能力的运行时。

Dapr官网 https://dapr.io

Dapr已经在多家大厂支撑生产环境

随着各家大厂的IT系统规模扩大，微服务架构已经成为了必需品和标准品，这也催生了 Dapr 这类非侵入式的（或者叫边车模式SideCar）的微服务开发框架的使用。根据Dapr官方仓库中的记录，已经有非常多的大厂在 生产环境 中使用Dapr来支撑自己的微服务开发。这里面不乏大家熟悉的腾讯，阿里，丁丁等国内大厂。

参考：

• https://github.com/dapr/dapr/issues/3169
• https://github.com/dapr/community/blob/master/ADOPTERS.md

Dapr比较SpringCloud或者Istio的优势在哪里？

这个可能是大多数人的第一个问题，简单总结几点供大家参考

• 全栈多语言支持：这一点上Dapr和Istio是等同的，因为都采用了边车模式，与应用进程之间没有有侵入性，相比SpringCloud这种只能支持Java语言（当然现在有很多其他语言提供SpringCloud的SDK）的侵入性框架，具备先天的跨语言优势。微服务化给开发人员带来的一个重要价值就是可以随意的选择不同开发语言框架进行组装，对于企业来说也可以避免被某一种技术框架绑定，甚至在招聘程序员的时候也可以有多的选择。因此当微服务的理念开始在业界流行以后，采用者的团队中必然出现多语言并存的状况。当你面对一个Java/.Net/Python/Node/JavaScript/Golang多语言并存并且相互依赖的应用环境的时候，就会发现SpringCloud无法这种需求，变成了微服务支撑框架的瓶颈。

• 多云/非云环境支持：这一点上Dapr和SpringCloud是等同的。SpringCloud作为云原生时代之前出现的框架，它本身的根基就在非云或者虚拟机环境上，因此SpringCloud本身就具备跨云/非云环境支撑，因为它本身和云环境并无绑定关系。你当然可以在容器/k8s中运行SpringCloud，但这仅仅是给SpringCloud应用换了一种打包部署方式而已。Istio 在这一点上有天然的弱势，因为Istio从一开始就诞生于云原生的基础设施k8s之上，也就顺其自然的利用了k8s所提供的很多基础能力，这些对于新生类应用来说非常合适，但是对于传统/现存应用来说就面临改造的问题。Dapr的设计则从根基上就兼容了多云/非容器和非云环境，同时也借鉴了云原生环境的特点来进行设计，因此你完全可以在传统的主机/虚拟机/非云环境中获得和云原生平台类似的微服务体验。这一点上对于已经有大量现存应用的传统企业来说，是非常重要的一个福音。×备注：Isitio也已经开始支持与虚拟机环境的集成，这一点大家可以自行查阅资料。

这个链接中介绍了阿里是如何引入 Dapr 以及背后的各种考量

• https://blog.dapr.io/posts/2021/03/19/how-alibaba-is-using-dapr/

简单来说，Dapr 从设计上就借鉴并考虑了之前的2种类似框架各自的优势，并将所有的好处融合进来，将弊端剔除掉；是当前最先进最有前途的分布式微服务开发框架。

搭建Dapr开发环境的痛点

以下视频是展示了在容器中使用 VSCode WebIDE 开发一个 Dapr 应用的整个过程

既然是一个面向微服务的开发框架，Dapr 环境本身可以变得非常复杂。因为要引入各种类型的中间件，很多开发者会发现搭建一个可以运行使用Dapr的环境，可能需要先安装一堆的各种服务。比如下面这个 Dapr 示例应用 Dapr-Traffice-Control

代码库

• https://github.com/SmartIDE/sample-dapr-traffic-control

虽然应用本身并不是特别复杂，只用到了3个服务组件，但是支撑这3个服务的中间件却有5个之多，包括：

• 作为 MQTT Broker 的 Mosquitto
• 常用的缓存中间件 Redis
• 消息队列 RabbitMQ
• 电子邮件发送中间件 SMTP 服务
• 密钥服务 Secrets

简单介绍一下这个示例的业务背景， dapr-traffice-control 模拟了一个常见的超速摄像头系统的实现，通过检测车辆通过道路上2个摄像头之间的耗时，计算车速，并发送罚单给司机。如下图：

这里用到的业务组件只有3个，分别是：

• TrafficControlService 是交通控制服务，也是主服务，其业务逻辑是根据公路上的2个固定位置摄像头反馈的数据，计算车辆通过摄像头的车速，以便判断是否存在超速行为。
• FineCollectionService 是罚单处理服务，根据 TrafficControlService 发送过来的车牌数据，查询车辆注册数据库（VehicleRegistrationService）获取联系人信息，并发送邮件
• VehicleRegistrationService 是车辆注册数据库，提供车辆信息查询，可以通过车牌号码获取车主信息，比如邮件地址。

这其实是微服务开发中一个非常普遍的问题：基础环境往往比应用本身还要复杂。这一点上和微服务的理念是相符的，微服务就是希望通过对不同业务组件的抽象尽量减少开发人员花在通用组件上的投入，而专注于业务本身。从这个角度来说， dapr-traffice-control 非常完美的诠释了这个理念；同时也非常直接的展示了这个困境。

从开发人员的角度来说，这带来的一个非常麻烦的问题：单体时代只要拿到代码就可以开始调试，现在的应用开发环境的搭建变得越来越复杂，开发人员需要了解的知识范围也被放大了。

实际上，以上这个问题在运维领域早就被完美解决了，方案其实就是容器和云原生技术本身。但是开发者作为云原生技术的使用者，自己没有从中获益，反而招来了更多的麻烦。

开发者不使用容器？

首先说明，这里所说的不是使用容器进行部署，而是使用容器进行开发。云原生的典型部署模式一定是容器化的，开发者在这个问题上并不纠结。开发者的现状是，虽然应用最终要在容器内运行，但是在开发的时候并不希望在容器内进行开发，主要原因是不方便，操作太繁琐以及对容器技术的不了解。这样带来的问题也非常显而易见，因为开发环境和生产环境不一致，就必须通过配置的方式，流水线自动化的方式来解决这些不一致的问题，造成整个发布系统变得更加复杂和难以维护。

要解决这个问题，我们必须降低容器的使用门槛，让开发者在 不了解/不学习 容器技术的前提下使用容器进行开发。SmartIDE就是为了解决这个问题而设计的，与繁琐的环境搭建脚本不同，SmartIDE 允许你使用一个简单的指令 smartide start 来启动 任何应用 的开发调试环境，而且这个环境从一开始就是容器化的。

对于上面这个 dapr-traffic-control 而言，启动命令如下

smartide start https://github.com/SmartIDE/sample-dapr-traffic-control

也就是说，开发者可以使用 smartide start 加上代码库地址来启动任何应用的开发调试；而且，如果开发者自己有一台可以运行Docker环境的云主机，那么就可以将这个 环境一键漫游 到这个主机上，整个过程只需要2个指令

## 添加主机到SmartIDE工具并获取 主机ID
smartide host add <Docker主机IP地址> --username <SSH登录用户名> --password < SSH登录用密码>
## 一键漫游环境到远程主机
smartide start --host <主机ID> https://github.com/SmartIDE/sample-dapr-traffic-control

完成以上操作后开发者就可以启动整个 dapr-traffic-control 的 环境进行开发调试了，效果如下

Dapr-traffic-control 开发调试过程

使用以上指令启动环境以后，开发者首先会获得一个类似VSCode的WebIDE界面，SmartIDE会自动启动浏览器并加载VSCode和应用代码，这时开发者可以打开内置的终端工具，使用 dapr init 初始化 Dapr开发环境。

这时，dapr 会启动3个docker容器，分别是 dapr: 1.7.4, zipkin 和 redis。默认情况下，dapr 会利用 docker 为开发者提供必要的中间件组件。要完成 dapr init 动作，开发者必须首先在本地安装 docker 环境，而在刚才的操作中，我们使用的是一个已经预装了 docker 的容器环境，也就是在容器内提供了 docker 的支持，这样开发者的环境完全处于容器内部，不再需要在开发机或者远程服务器上安装这些服务， 这种环境我们称之为 VM Like Container （VMLC），也就是类虚拟机容器环境，后续我们会专门针对VMLC进行更加详细的介绍。这种方式也同时保证了无论开发者在什么地方启动这个环境，都可以获得一致的体验。

现在，键入 docker ps 就可以看到这3个容器已经启动完毕

现在，我们通过一个预先准备好的 PowerShell 脚本来启动 Traffice-Control 应用的其他中间件环境，同样，这个过程中你也不必考虑 PowerShell 工具是否存在的问题，因为这些都已经通过标准化的 开发者镜像 提供了。你只需要在终端中执行

cd src/Infrastructure/
pwsh start-all.ps1

你会注意到我们实际上在容器内执行了一系列的 docker build 和 docker run 的动作，完成了另外3个中间件容器的启动，分别是：

• Maildev: 1.1.0 - 负责模拟电子邮件发送和接受的调试工具
• Rabbitmq: 3-management-alpine - 消息队列服务
• Mosquitto: 1.0 - MQTT Broker 服务

如果再次运行 docker ps，你可以看到现在我们已经有了6个容器运行在环境中，构成了当前应用的完整中间件环境。现在我们就可以依次启动3个业务组件，完成整个 traffic-control 应用的开发调试了。分别启动3个终端窗口，进入 src/TrafficControlService, src/VehicleRegistrationService, src/FineCollectionService，并运行启动指令

## 使用PowerShell脚本启动服务
pwsh start-selfhosted.ps1

最后，我们来启动模拟器。进入 src/VisualSimulation 目录并运行以下指令

dotnet run 

现在，我们可以开启另外2个浏览器窗口，分别打开

• http://localhost:5000 - 模拟器窗口，可以看到随机出现的汽车通过摄像头的场景，同时调用以上业务服务，模拟交通流量。
• http://localhost:4000 - 邮件模拟应用，可以持续收到邮件/超速罚单的过程

至此，我们完成了整个 dapr-traffic-control 示例应用的调试。在这个过程中，开发者不必了解背后的 Docker，远程SSH隧道，容器镜像环境的各种配置；而且，无论开发者在自己的本地开发机，还是远程主机，或是k8s集群中启动这个环境，都可以使用统一的 smartide start 指令来完成。

SmartIDE 的设计初衷就是希望能够最大程度的降低开发者上手一个应用的复杂度，无论这个应用是一个简单的hello-world，还是一个复杂的微服务应用；也无论应用所需要的环境只是简单的SDK，还是各种复杂中间件以及繁琐的网络配置，都只需要一个指令：smartide start

SmartIDE支持跨平台，全技术栈和多种IDE工具（VSCode/JetBrains全家通/OpenSumi)；对于独立开发者以及中小型企业用户是完全免费并且开源的。如果你希望马上尝试一下这种全新的应用开发方式，请参考以下链接：

• 官网 https://SmartIDE.cn
• B 站频道 https://space.bilibili.com/1001970523
• GitHub 开源地址 https://github.com/smartide
• Gitee 开源地址 https://gitee.com/smartide

社区早鸟计划

如果你对云原生开发环境感兴趣，请扫描以下二维码加入我们的 SmartIDE社区早鸟计划

谢谢您对SmartIDE的关注，让我们一起成为云原生时代的 Smart开发者, 享受 开发从未如此简单 的快乐。

让我们一起成为 Smart开发者，享受开发如此简单的乐趣。

README.exe

作为开发者，拿到一个新的代码库的时候一般都会先去看README文件，通过这个文件可以知道这套代码所需要安装的环境，工具和操作方式。这件事情本来应该是一件很愉悦的事情，因为每一套新代码其实都是开发者的新玩具，拿到新玩具的心情那肯定是不错的。但是，当你阅读玩具说明书之后，发现这份说明书完全不配套的时候，那心里一定是一万匹草泥马在奔腾。当然，这也很容易理解，开发者不爱写文档，特别是那些没有用的文档。至少，README对写的人来说其实没啥用，因为写的人都已经清楚了文档中的内容，至于看的人感受如何，那就呵呵吧。

这个问题的根源在于README只能看，不能运行！如果我们能够让README活起来，从 README.md 变成 README.exe，那是不是就可以解决这个问题了呢？答案是肯定的！因为写的人自己也可以用这份文档来启动项目。这样，写文档的人有了动力，看（运行）文档的人也会很爽。

这就是SmartIDE的核心功能: IDE as Code能力。

神奇的IDE配置文件

SmartIDE最初始的设计灵感就是如何能够让README活起来？为了做到这一点，我们设计了一个 IDE配置文件 (默认文件名 .ide.yaml）文件格式。这个文件中完整描述了运行当前代码所需要的环境配置，包括 基础环境SDK，应用服务器，应用端口，配置文件，网络依赖以及所使用的IDE工具。有了这个文件，开发者就可以真正实现一键启动开发调试，而不会再听到：“在我这里工作呀，是你的环境问题！” 这种骇人听闻的抱怨。

有了这个文件，任何人都可以使用一个简单的指令来一键搭建一模一样的开发环境，指令如下：

smartide start https://github.com/idcf-boat-house/boathouse-calculator

这个指令会自动识别代码库中的 IDE配置文件，根据文件中对开发环境的描述完成获取开发者镜像、启动开发容器、克隆代码、运行初始化脚本等一系列动作，最终一个 完整可运行的环境 呈现在开发者的面前，下面这段视频展示了整个运行过程：

IDE配置文件详解

以上示例中所使用的 .ide.yaml 文件如下

version: smartide/v0.3
orchestrator:
  type: docker-compose
  version: 3
workspace:
  dev-container: # 开发者容器设置
    service-name: boathouse-calculator
    
    ports: # 申明端口
      tools-webide-vscode: 6800
      tools-ssh: 6822
      apps-application: 3001
    
    ide-type: vscode  #sdk-only | vscode | opensumi | jb-projector
    volumes: # 本地配置映射，支持映射git-config和ssh密钥信息进入容器
      git-config: true
      ssh-key: true
    command: # 环境启动脚本
      - npm config set registry https://registry.npmmirror.com
      - npm install
  services:
    boathouse-calculator:
      image: registry.cn-hangzhou.aliyuncs.com/smartide/smartide-node-v2-vscode:all-version
      restart: always
      environment:
        ROOT_PASSWORD: root123
        LOCAL_USER_PASSWORD: root123       
      volumes:
      - .:/home/project
      ports:
        - 3001:3001
        - 6822:22
        - 6800:3000
      networks:
        - smartide-network

  networks:
    smartide-network:
      external: true

这个文件内容非常通俗易懂，是个程序员应该都能看明白，不过我还是简单说明一下：

• orchestrator - 环境调度工具设置，用来制定调度容器环境的底层工具，这里我们使用的是 docker-compose
• workspace - 工作区配置，工作区 是SmartIDE中最重要的概念，包含开发者用来进行开发调试的所有环境信息
  • dev-container - 开发者容器设置
    • service-name - 开发者容器所对应的 docker-compose 服务名称
    • ports - 开发者容器对外暴露的端口
    • ide-type - 开发者容器所所用的IDE类型，支持：vscode, sdk-only, jb-projector (Jetbrains系列全家桶）和 opensumi
    • volumes - 配置映射，支持将开发者的git-config和ssh密钥导入容器
    • commands - 开发环境启动脚本，对环境进行初始化；比如以上脚本中就完成了2个关键操作：1）设置npm国内镜像源 2）获取npm依赖。这部分脚本开发者可以根据自己代码库的情况设置，SmartIDE会在环境启动后自动运行这些脚本，让程序处于开发者所希望的状态上。
• services - 开发环境内的服务列表
  • 这里其实就是一段标准的 docker-compose 配置文件

IDE as Code 重新定义IDE

这种做法称为 IDE as Code 也就是 “集成开发环境即代码”，将你的开发环境配置变成一个 IDE配置文件 的配置文件放置在代码库中，然后根据这个配置文件生成对应的自动化脚本，完成“集成开发环境” 的创建。因此，SmartIDE中的IDE不仅仅是一个开发工具，而是 包含了环境的IDE。

IDE as Code 的做法源自DevOps的核心实践 Infrastructure as Code ，也就是 “基础设施即代码” 简称 IaC。其核心思想是将环境配置代码化，常见的k8s的yaml文件其实就是典型的基础设施即代码实现。在运维领域常用的工具比如chef/puppet/ansible，还有 HashiCorp 的 Terraform 也都是 IaC 的经典实现。IaC 的主要价值和目标就是将环境搭建过程标准化，让任何人在任何环境中都可以获得 一致、稳定、可靠 的环境搭建体验。SmartIDE所创造的 IDE配置文件 延续IaC了的使用场景，并将其基本思路应用到了开发测试环境中，这其实就是 SmartIDE 的产品核心能力。

基于 IDE as Code 的实现，SmartIDE在产品实现过程中一直秉承一个原则：能够让用户通过配置文件实现的东西，就不要通过代码实现。这个核心原则给予了SmartIDE非常强的灵活性，比如以下这段视频中所演示的 若依管理系统 项目

这个项目包括比较复杂的环境配置，包括：

• JDK 基础环境
• MAVEN 包管理工具
• MySQL 服务器
• Redis 服务器
• 可选：数据库管理工具 PHPMyAdmin

若依项目的官方文档用了整整2页的篇幅描述开发环境的搭建 (参考链接：环境部署 | RuoYi） 。使用了 SmartIDE 以后，开发者可以一个统一的指令 smartide start 来启动这个复杂的项目，不再需要去阅读这个文档。无论项目的代码是简单亦或复杂，smartide start 指令都可以进行适配，因为其背后的复杂配置已经全部通过 IDE配置文件 和代码保存在一起了。使用 IDE as Code 的另外一个好处是，由于配置和代码保存在一起，进行代码变更的开发者可以同步更新环境配置，并且一起提交进行评审，也就是说：你的环境也和代码一样是可评审，可审计的。

IDE文件配置就是README活文档。

当然，SmartIDE能做的绝不仅仅如此，我们已经发布了 SmartIDE Server 版，允许开发者在网页上即可完成开发环境的搭建和完整的开发调试过程。Server与CLI一样使用这个 IDE配置文件 来识别和搭建环境，与cli保持一致的体验。这一切的目的都是让开发者的日常工作变得简单，让开发者体验 #开发从未如此简单 的快乐。

如果你对云原生开发环境感兴趣，请扫描以下二维码加入我们的 SmartIDE社区早鸟计划

谢谢您对SmartIDE的关注，让我们一起成为云原生时代的 Smart开发者, 享受 开发从未如此简单 的快乐。

2022年5月10日

版本日志

SmartIDE v1.0.25 统一配置文件和Codespaces for Azure DevOps插件

SmartIDE v1.0.25 (CLI build 5383, Server Build 5503) 已经发布，这个版本中我们针对一些关键特性进行了重要重构，比如 统一配置文件 和 工作区策略；同时我们还发布了一键启动链接和 SmartIDE Codespaces for Azure DevOps 插件，允许开发者在Azure DevOps上直接启动SmartIDE工作区；具体列表如下：

• 统一配置文件：开发者可以使用一个.ide.yaml 文件同时支持本地/远程/k8s三种模式的工作区配置
• 一键启动链接：允许开发者将这个链接放置在README文件，博客或者任何网页上，直接点击即可启动工作区
• Azure DevOps插件：允许开发者在Azure DevOps的代码库，流水线和工作项上一键启动SmartIDE工作区
• 工作区策略改进：增加了credential策略，方便开发者为k8s工作区设置密码，同时允许开发者使用这个密码通过SSH登录工作区

统一配置文件

这个版本中我们开始允许使用一个 .ide.yaml 同时支持本地，远程和k8s三种工作区模式的配置。由于我们使用了 docker-compose 和 k8s manifest 两种环境编排，在之前的版本中用户需要针对2种编排模式提供至少2个不同的 .ide.yaml 文件，并且需要在启动的时候特意指定不同的配置文件，才能在不同类型的资源上启动工作区。现在开始，我们支持使用一个统一的.ide.yaml作为多种环境资源的入口，比如以下配置文件：

version: smartide/v0.3
orchestrator:
  type: allinone
  version: 3
workspace:
  dev-container:
    service-name: boathouse-calculator-dev
    webide-port: 6800
    ports: 
      tools-webide-vscode: 6800
      tools-ssh: 6822
      apps-application: 3001
    ide-type: vscode  
    volumes: 
      git-config: true
      ssh-key: true
    command:
      - npm config set registry https://registry.npmmirror.com
      - npm install
  kube-deploy-files: "k8s-deployment.yaml" 
  docker-compose-file: "docker-compose.yaml"

几个关键点：

• Line 3 - orchestrator 的类型指定为 allinone，之前的选项是 docker-compose 或者 k8s
• Line 20 - 指定k8s环境的编排文件
• Line 21 - 指定本地和主机环境的编排文件

使用统一配置文件之后，开发者可以使用统一的指令格式在三种不同资源上启动工作区，比如以下指令

## 本地启动 (windows/mac/linux)
smartide start https://github.com/idcf-boat-house/boathouse-calculator.git
## 远程主机启动
smartide start --host <hostId> https://github.com/idcf-boat-house/boathouse-calculator.git
## k8s启动
smartide start --k8s <context> https://github.com/idcf-boat-house/boathouse-calculator.git

可以看到，以上启动指令中只是增加了 --host 或者 --k8s 参数，其他部分完全一致。 另外，使用了统一配置文件之后，开发者也可以直接使用现有的 docker-compose 文件 或者 k8s 配置文件，不再需要复制这些文件的内容放入到我们的 .ide.yaml 中，这将简化开发者使用SmartIDE的准备工作。

网页链接一键启动

开发者现在可以使用类似以下的链接格式直接触发工作区的创建

https://dev.smartide.cn/#<Git代码库URL>

比如，以下就是一个可以直接触发工作区创建的链接，点击这个链接将会自动为boathouse-calculator库创建工作区

• https://dev.smartide.cn/#https://github.com/idcf-boat-house/boathouse-calculator

你也可以在自己的README.md上放置一个 smartide start 的徽章，并在徽章上使用这个链接

以下视频展示了使用 网页链接一键启动 Github代码库的场景

SmartIDE Codespaces for Azure DevOps 插件

基于以上 一键启动链接 能力 ，我们为 Azure DevOps 平台提供了一个插件，允许用户在不同的位置按照当前的上下文启动工作区，自动获取代码库地址，分支名称等参数，简化开发者创建开发环境的准备工作。这些自动化操作可以简化开发者从日常任务中进入编码环境的操作，并实现全线上化操作。

以下视频是在早鸟用户姚圣伟访谈过程中对这个插件的演示过程：

这个插件和已经发布到了 Azure DevOps 的插件市场，链接如下

• SmartIDE Codespaces for Azure DevOps 插件

这个插件提供了4类入口，分别是

1. 代码库： 用户可以在任何分支或者提交记录上启动工作区，插件会自动识别当前代码库地址和分支名称，并使用这些参数启动一个与当前代码版本一致的开发环境。

2. 拉取请求： 使用拉取请求（PR）进行代码评审是非常普遍的开发实践，但是评审者往往会因为无法看到软件的运行情况而无法对当前正在评审的内容进行有效和完整的判断。此时，评审者就可以直接点击 Open in SmartIDE 按钮，即可获取一个和当前被评审代码完全一致的，可运行的环境来辅助进行代码评审，这会让评审工作变得更加简单和高效。评审者在整个过程中也无需安装任何开发工具，SDK和中间件环境，所有的环境都通过SmartIDE自动创建完成。评审结束后这个环境就可以直接销毁。

3. 流水线： 一次流水线执行代表一个软件版本，测试人员一般是需要围绕这样的版本来进行测试的。传统模式下，测试人员需要准备几套测试环境来轮流测试不同的版本，如果出现多个版本并行的情况就很难管理这些测试环境。使用了SmartIDE之后，测试人员可以随时在任何版本（流水线运行记录）上点击 Open in SmartIDE 按钮，即可获取一个和当前流水线运行版本一致的环境进行测试；并且，这个环境中还包含了可供开发人员直接进行调试的IDE工具。测试过程中如果发现问题，测试人员可以将这个环境直接共享给开发者进行问题定位和调试。这种随用随起的测试环境将极大简化测试人员获取可用测试环境，以及在测试环境中定位问题的复杂度，提高开发测试迭代速度。

4. 看板工作项： 使用特性分支对应到具体工作任务是大型软件开发团队中常用的分支策略，也是一种高效团队协作模式。以往开发者需要手工创建分支，并在本地开发环境拉取代码并手工切换到这个分支上才能开发工作。如果遇到同时在2个特性上工作的情况，繁琐的分支操作很容易造成操作失误。现在，开发者可以在工作任务上直接点击 Open in SmartIDE 按钮并根据需要创建或者使用已有分支，SmartIDE会自动使用指定分支创建开发环境。对于多特性并行情况，开发者只需要打开2个不同的浏览器窗口即可同时在2个分支上互不影响的进行工作。

SmartIDE Codespaces for Azure DevOps 插件只是我们计划提供的各种插件的一个示例，未来我们还将为常用的DevOps工具提供类似的入口，比如：Jira, Confluence, GitLab, Jenkins等等。这些扩展将帮助现有的DevOps工具与开发环境及编码过程实现更加紧密的集成，为开发人员提供一体化的工作体验。

工作区策略改进

工作区策略是SmartIDE中针对工作区进行各种控制的通用能力，之前我们已经提供了 Git Config 和 SSH Key 两种策略分别用来控制工作区中的git配置和ssh密钥。这个版本中我们增加了统一设定工作区访问密码的credential策略，一旦设定，开发者就可以使用一个统一的密码来控制对自己工作区的访问，包括SSH访问。

对于原有的SSH Key策略，我们进一步完善了密钥的推送过程，帮助开发者在使用SSH远程连接的时候实现免密登录。

下图：开发者获取SSH登陆指令并直接进入工作控制台终端。

开发者也可以使用这个指令将本地VSCode或者JetBrains IDE连接到工作区，整个过程无需输入密码。

下图：使用VSCode远程模式免密进入SmartIDE云端工作区

感谢你对SmartIDE的关注，欢迎从SmartIDE官网下载体验我们的产品，获取加入我们的早鸟群，及时了解SmartIDE的开发进展。

SmartIDE v1.0.23 一个非常不敏捷的发布

本次发布包含Sprint 20-23的内容，包括的特性有：完整的k8s模式支持，团队管理能力，简化使用本地IDE（VSCode/JetBrains Gateway）连接SmartIDE工作区的Hybrid模式，工作区扩展组件Web Terminal，ARM处理器支持以及Gitlab CI/CD流水线支持。另外，我们也扩展了VMLC的支持范围，对 node 和 java 两种技术栈提供了对应的 VMLC 开发者镜像。

CLI代码正式开源

我们已经完成 CLI 代码的开源，相关代码已经推送到我们在GitHub和Gitee上面的代码仓库，包括全套CLI代码（Golang语言编写，采用GPLv3开源协议）。这套代码从2021年10月24日开始迭代，至今已经完成了700多次提交并发布了超过4000个版本，希望我们开源以后能够有更多社区小伙伴参与进来。

开源地址：

• https://github.com/SmartIDE/SmartIDE/tree/main/cli
• https://gitee.com/smartide/SmartIDE/tree/main/cli

完整k8s模式

我们已经发了完整的k8s模式支持，独立开发者可以使用CLI将SmartIDE工作区一键部署到k8s集群中，团队管理员则可以通过SmartIDE Server将k8s集群共享给团队中的开发者共享使用。当使用SmartIDE Server创建k8s工作区的时候，会同时创建指向工作区的动态二级域名URL以及ssh连接地址，开发者可以直接通过这个动态二级域名访问自己的工作区。这意味着开发者可以通过任何设备访问运行在k8s中的SmartIDE工作区，包括传统PC，平板电脑/iPad以及手机。

CLI 启动k8s

这种方式适合个人开发者使用自己私有的k8s集群作为开发调试环境使用，开发者只需要在本地配置了k8s访问密钥（默认位置 ~/.kube/config），即可通过以下指令将SmartIDE云端工作区部署到k8s集群中。一旦启动完毕，cli会通过k8s的kubectl指令自动完成工作区内容器端口到localhost端口的映射，开发者即可通过 localhost 上的端口访问这个运行在k8s中的工作区。

使用CLI直接部署k8s工作区示例脚本如下

## cli 一键部署k8s工作区指令
smartide start --k8s <当前集群> \
  --repourl https://github.com/idcf-boat-house/boathouse-calculator.git \
  --filepath .ide/k8s.ide.yaml
## cli 获取工作区列表指令，可以用来获取 工作区Id 并查看工作区运行状态
smartide list
## cli 删除工作区
smartide remove <工作区Id>

下图：使用cli启动完成k8s工作区效果如下，同时使用VSCode WebIDE，VSCode桌面版和JetBrains Webstorm远程模式连接k8s工作区。

Server启动k8s工作区

SmartIDE Server支持一键私有部署，你只需要一台Linux主机即可完成部署，并不依赖k8s集群。在完成Server的部署之后，管理员可以将一个或者多个k8s集群绑定在Server上，并将这些k8s集群分配给不同的团队使用。

下图：同时绑定了3个k8s集群和一台linux主机的SmartIDE Server环境

使用Server部署k8s工作区非常简单，只要在 工作区 | 工作区管理 | 新增工作区 的时候选择对应的k8s资源即可。

下图：使用k8s资源新增工作区

通过k8s工作区对外暴露的ssh连接地址，开发者可以直接使用本地终端程序连接到SmartIDE工作区并通过terminal完成各种操作。同时，开发者也可以使用VSCode以及JetBrains Gateway的ssh远程连接能力将本地的VSCode或者JetBrains系列的IDE（包括：IntelliJ IDEA, PyCharm, GoLand, WebStorm等等）连接到SmartIDE的远程工作，这样开发者可以同时兼顾本地IDE的快速操作体验以及远程工作区带来的各种好处。

下图：使用Server启动的k8s工作区，同时通过VSCode WebIDE, VSCode桌面端和IDEA IntelliJ远程模式连接工作

SmartIDE工作区提供VMLC支持，你可以在自己的k8s集群上激活VMLC能力，然后就可以在运行在k8s集群中的SmartIDE工作区内部嵌套运行docker或者k8s集群。开发者可以使用VMLC能力非常方便的创建和销毁属于自己的k8s集群，并使用这个个人k8s集群完成云原生应用的完整开发测试和部署迭代，这将简化开发者开发云原生应用的复杂度，并有效减少在正式集群上部署出错的机率，大幅提升云原生应用的开发效率。

相关文档参考：

• Server私有部署操作手册
• 为SmartIDE Server初始化k8s集群
• 【开源云原生大会】现场演示：k8s套娃开发调试dapr应用
• 为什么Dapr是比SpringCloud和Istio更优雅的微服务框架？
• SmartIDE Server 快速启动教程

团队共享资源

SmartIDE Server中新增了团队管理能力，开发者可以根据需要创建团队并将其他用户加入团队。团队的创建者会成为当前团队的管理员，作为管理员可以将主机或者k8s集群绑定到团队并允许其他团队成员使用这些资源来创建工作区。

下图：团队资源会显示所属团队

Hybrid混动模式优化 - VSCode SSH Remote 和 JetBrains Gateway 支持

我们简化了VSCode SSH Remote连接SmartIDE工作区的操作步骤，当开发者使用CLI启动工作区的时候，CLI会自动在 .ssh/config 文件中添加远程连接，这时开发者只需要打开VSCode的远程连接插件，即可看到已经配置好的远程连接，直接点击即可完成连接。在这个过程中，SmartIDE还会自动更新远程工作区容器中的 ~/.ssh/authorizedkeys 文件，将本地的ssh公钥添加进去，这样开发者在连接远程工作区的时候就不再需要输入密码，可以实现一键连接。

对于更喜欢使用JetBrains系列IDE的开发者来说，你仍然需要手工在JetBrains Gateway中创建远程连接才能使用Hybrid模式，不过以上的authorizedkey设置对JetBrains Gateway同样有效，因此连接过程也会更加简单。我们后续也会继续优化对JetBrains远程工作模式的支持，实现一键连接能力。

WebTerminal 支持

为了方便开发者使用terminal访问SmartIDE工作区，我们提供了一个工作区扩展（Workspace AddOn），开发者可以在创建工作区的时候添加 –addon webterminal 即可在工作区中添加基于浏览器的终端窗口。虽然在VSCode以及JetBrains的WebIDE中都提供了terminal功能，但是提供一个独立的终端窗口仍然会大幅方便开发者对工作区进行管理，比如当你需要运行一个驻守进程，需要访问工作区中的其他容器或者希望使用类似Vim编辑器时。

通过添加 –addon webterminal 参数到本地/主机模式的cli启动命令中即可在环境中增加WebTerminal功能，示例指令如下

## 添加 --addon webterminal 启动工作区
 smartide start --host 1 --addon webterminal https://github.com/idcf-boat-house/boathouse-calculator.git

下图：通过WebTerminal可以访问当前工作区中的所有容器，并支持对terminal进行分屏，方便并行操作。

SmartIDE WebTerminal是我们基于开源项目 ysk2014/webshell 改造完成的，因此采用和原项目同样的MIT开源协议。WebTerminal也是我们提供的第一个工作区扩展(Workspace Addon)，后续我们会逐步提供更多的扩展，加强开发者对远程工作区的操作能力。

SmartIDE WebTerminal 的开源地址：

• https://github.com/SmartIDE/smartide-web-terminal
• https://gitee.com/smartide/smartide-web-terminal

ARM支持

本次迭代我们提供了对ARM处理器的支持，当前ARM处理器已经在很多领域得到了大规模的应用，包括：PC机（苹果的M系列电脑），移动设备，边缘计算及IoT以及服务器。SmartIDE与其他CloudIDE不同的是，我们将云端/远程工作区的调度能力封装成了一个独立的cli程序（已开源），并利用go语言的跨平台特性支持在多种操作系统上运行cli，这为SmartIDE提供了其他任何CloudIDE都不具备的跨平台跨设备运行能力。这次我们针对ARM处理器进行的支持进一步将我们的跨端能力进行了大幅的扩展，未来我们将探索将CloudIDE嵌入到移动设备，边缘计算和IoT领域，为开发者提供无所不在的开发环境管理能力。

我们同时优化了安装脚本，提供了ARM版本对应的安装通道，包括MacOS和Linux两种操作系统。

Mac稳定版安装

# MacOS

# Intel芯片
curl -OL  "https://smartidedl.blob.core.chinacloudapi.cn/releases/$(curl -L -s https://smartidedl.blob.core.chinacloudapi.cn/releases/stable.txt)/smartide-osx" \
&& mv -f smartide-osx /usr/local/bin/smartide \
&& ln -s -f /usr/local/bin/smartide /usr/local/bin/se \
&& chmod +x /usr/local/bin/smartide

# Apple芯片（比如M1/M2系列）
curl -OL  "https://smartidedl.blob.core.chinacloudapi.cn/releases/$(curl -L -s https://smartidedl.blob.core.chinacloudapi.cn/releases/stable.txt)/smartide-osx-arm64" \
&& mv -f smartide-osx-arm64 /usr/local/bin/smartide \
&& ln -s -f /usr/local/bin/smartide /usr/local/bin/se \

Linux稳定版安装

# Linux 
# x86 架构处理器
curl -OL  "https://smartidedl.blob.core.chinacloudapi.cn/releases/$(curl -L -s https://smartidedl.blob.core.chinacloudapi.cn/releases/stable.txt)/smartide-linux-amd64" \
&& sudo mv -f smartide-linux-amd64 /usr/local/bin/smartide \
&& sudo ln -s -f /usr/local/bin/smartide /usr/local/bin/se \
&& sudo chmod +x /usr/local/bin/smartide

# arm 架构处理器
curl -OL  "https://smartidedl.blob.core.chinacloudapi.cn/releases/$(curl -L -s https://smartidedl.blob.core.chinacloudapi.cn/releases/stable.txt)/smartide-linux-arm64" \
&& sudo mv -f smartide-linux-arm64 /usr/local/bin/smartide \
&& sudo ln -s -f /usr/local/bin/smartide /usr/local/bin/se \
&& sudo chmod +x /usr/local/bin/smartide

下图：在一台 Apple MacPro M1 上使用ARM原生版本的SmartIDE CLI运行容器化工作区

本次我们对ARM处理器所提供的支持包括

• Linux和MacOS操作系统版本的cli提供amd64和arm64两种build，并已经发布至每日构建和稳定版通道
• SmartIDE Server相关镜像（smartide-web和smartide-api）的arm版镜像以及相关依赖镜像（包括tekton流水线相关的基础组件镜像），已经推送至阿里云镜像仓库和DockerHub
• 包含 smartide-cli arm64版本的 tekton-task 镜像，已经推送至阿里云镜像仓库和DockerHub
• 开发者镜像的arm版本，已经推送到阿里云镜像仓库和DockerHub
• Server一键部署脚本提供了内置的arm支持，可以自动识别当前部署环境，自动使用arm相关资源，具体请参考 Server私有部署操作手册

具体资源内容和链接可以参考

• https://github.com/SmartIDE/SmartIDE/issues/29

GitLab CI 流水线支持

我们将SmartIDE的核心功能设计成CLI的一个主要考虑就是允许开发者以最低的成本，最简单的方式将 云原生IDE 的能力集成到自己的系统中。在本次迭代中，我们开始进一步践行这个使命，在 CLI中提供了一个 mode=pipeline 的运行模式，这个模式允许用户在自己的流水线中使用 SmartIDE CLI 去创建工作区，本次只开放了远程主机模式，未来也会开放k8s模式。

使用场景：

• 扩展现有的企业流水线系统变成一个CloudIDE管理系统
• 部署带有对应版本代码的测试环境，这将方便开发者对测试环境中的问题进行定位并直接在测试环境中进行调试
• 针对某一个特定的历史版本创建开发调测环境，当我们收到用户的缺陷报告时往往发现自己开发环境中的代码版本已经大大超前于用户使用的版本了。这种情况开发者可以使用SmartIDE创建一个临时的环境，并直接定位于一个特定的历史版本（直接使用commitId），这样可以避免污染开发者本地，也可以避免开发者在修复问题之后将新版本（未经测试）的代码通过HOTFIX夹带上线。

使用方法非常简单，将下面 .gitlab-ci.yml 放置在自己的gitlab代码库中即可扩展 gitlab-ci 流水线具备管理 云原生IDE 的能力。

variables:

  #remote host information which you can deploy your dev workspace and open it in WebIDE
  SMARTIDE_REMOTE_HOST: <remote dev/test env>
  SMARTIDE_REMOTE_HOST_USERNAME: <host username>
  SMARTIDE_REMOTE_HOST_PASSWORD: <host password>
  #git repo you want to develop in smartide,  you can use predefined variable  $CI_REPOSITORY_URL 
  #for the URL to clone the current Git repository (the URL already contain token, so you dont need to 
  #consider Authentication problem, for custom git repo url, you need resolve authentication yourself with token or ssh..)
  SMARTIDE_GIT_REPO_ADDRESS: $CI_REPOSITORY_URL
  #callback api address which you want to receive workspace information and trigger other custom events
  SMARTIDE_CALLBACK_API_ADDRESS: <callback api address>

stages:
    - setup_dev_env

smartide:
    stage: setup_dev_env
    image: 
        name: registry.cn-hangzhou.aliyuncs.com/smartide/smartide-cli:4475
        entrypoint: [""]
    script:
        - smartide version
        - smartide start --mode pipeline --isInsightDisabled false --host $SMARTIDE_REMOTE_HOST --username $SMARTIDE_REMOTE_HOST_USERNAME --password $SMARTIDE_REMOTE_HOST_PASSWORD --callback-api-address $SMARTIDE_CALLBACK_API_ADDRESS $SMARTIDE_GIT_REPO_ADDRESS

以上gitlab-ci流水线脚本将会使用当前的代码库创建云端工作区，开发者可以通过定制 .ide.yaml 配置文件在这个云端工作区中嵌入自己所需要的IDE，中间件或者其他环境，具体做法请参考 项目适配 和 镜像和模版。

本次迭代中我们针对 SmartIDE CLI 的现有功能进行了简单扩展，在现有的 client | server 两种运行模式之上提供了 pipeline 的运行模式。这种模式其实是一种headless模式，cli不会试图打开浏览器，也不会调用 smartide server 的 api，而是允许用户自行指定一个 callback 地址 $SMARTIDE_CALLBACK_API_ADDRESS。当CLI完成工作区创建工作后，会按照既定json格式将工作区详情回调通知给这个地址。使用这种方式，开发者可以非常简单的将 CloudIDE能力 集成到现有的企业级DevOps平台中，需要的仅仅是一个流水线调度工具（gitlab-ci, jenkins, azure pipeline或者其他任何支持命令行调用的工具）和一个接收回调json格式的接口。

本次提供的gitlab-ci集成示例只是一个开始，当前SmartIDE CLI的特性已经形成闭环，我们在后续迭代中会开始探索提供更多的集成方式，让开发者可以以最简单的方式享受到云端开发的好处。

有关gitlab-ci支持的详情请参考：

• https://github.com/SmartIDE/SmartIDE/issues/30

使用云原生技术赋能开发者，是我们一贯的使命。

SmartIDE v0.1.19 - Gitee GVP、工作区策略、类虚拟机镜像VMLC、Server安装手册

码云（Gitee.com）最有价值开源项目奖项

SmartIDE在上周获得了码云（Gitee.com） 的最有价值开源项目奖项。码云（Gitee.com）是国内最大的开源代码托管平台，当前有800万开发者用户。GVP - Gitee最有价值开源项目奖项需要开源项目采用OSI认可的License (SmartIDE采用GPL3.0协议），通过Gitee专家组的认可，开发活跃度（SmartIDE至今已经完成了488次代码提交），积极响应用户反馈，提供完整的文档以及用户评价（当前Gitee Star 125, Github Star 229）。

SmartIDE非常荣幸获得码云的认可，我们将继续为开发者提供最好的开发工具和技术支持。

Server 私有部署手册

SmartIDE Server 是面向团队和企业的云原生容器化远程工作区管理平台，可以为开发团队提供统一的开发测试资源管理，基于浏览器的开发环境访问以及团队协作能力。SmartIDE Server 的 团队基础版 功能是开源而且免费的，任何人都可以按照本手册所提供的方式完成部署并免费使用，没有使用期限限制，没有用户数限制，也没有资源数量限制。

下图是Server版的部署架构图：

图中可见，SmartIDE Server 采用了非常灵活并且可扩展的分布式架构，每个服务组件都可以进行独立的横向扩展以便确保可以应对不同规模的部署模式需求。既可以在单台Linux主机上完成完整的部署，也可以在k8s集群上支持高可用，高性能的可横向扩展部署，对于不同规模的团队都可以提供支持。

我们已经完成了 SmartIDE Server 私有化部署的文档验证，包括公网部署和隔离网络部署均已经可以投入使用。希望尝试自行部署的小伙伴现在就可以参考以下完成完成部署和功能验证：

• Server 部署手册
• SmartIDE Server 快速开始

类虚拟机容器 VMLC

在2022年6月11日刚刚结束的 开源云原生开发者日 大会上，我进行了名为 【寻找云原生时代的开发者效能原力 - 使用AKS实现云原生IDE开发调试环境】的主题演讲，并在演讲中首次展示了 SmartIDE 对 VMLC 的支持。

类虚拟机容器 VMLC 是 VM Like Container 的缩写，其设计目标是为开发者在容器中提供类似虚拟机的环境，包括：systemd服务管理能力，sshd远程登录能力，docker/k8s嵌套能力等。容器化技术出现以后，绝大多数的使用场景都是生产环境，因此对容器的优化目标都是围绕精简，单一进程，不可变状态的目标来实现的；对于开发人员来说，按这种目标设计的容器并不适合作为开发环境来使用。相对于生产环境中已经预先确定的配置，开发环境的配置需要由开发人员根据当前应用的不同需求进行持续的调整，并且持续的进行内迭代过程（Inner Cycle），这个过程包含了编码，编译打包，部署，测试，修复的过程。只有为开发人员提供完整的内迭代能力才能最大限度确保开发人员提交的代码质量，降低后续环节（包括生产环境）中出现问题和缺陷的几率。

为了达到以上目标，SmartIDE产品团队在过程的Sprint 18-19两个迭代中完成了VMLC容器标准的设计，验证和实现，并且已经通过 dapr-traffic-control 示例应用展示了 VMLC 的完整能力，包括：

• 在Linux主机和k8s集群中部署 VMLC 远程工作区容器的能力
• 使用 smartide start指令或者 smartide new 指令启动基于 VMLC 的远程工作区的能力
• 使用 SmartIDE Server 管理基于 VMLC的远程工作区的能力
• 在VMLC容器中运行docker能力
• 在VMLC容器中运行多节点k8s的能力，包括使用LoadBalancer, Ingress提供外部访问的能力
• 使用SSH链接VMLC容器，并使用终端进行操作的能力
• 使用VSCode远程开发插件 / JetBrains Gateways 链接 VMLC 容器进行 Hybird 模式开发的能力 当前，我们已经提供了以下基于 VMLC 的开发者镜像，其他类型的开发者镜像会在后续的 Sprint 中完成适配

有关基于 VMLC 的 SmartIDE 远程工作区详情，请参考以下博客

• 【开源云原生大会】现场演示：k8s套娃开发调试dapr应用

工作区策略

工作区策略是为远程工作区提供配置管理能力的一个通用特性，通过运行于远程工作区中的代理程序，SmartIDE可以针对特定工作区内部的环境进行所需要的各种配置。其架构如下

如上图，工作区策略的实现通过agent来实现，agent和server之间是单向通信(pull)的模式，因此工作区并不需要为sever开放网路服务端口，agent会按照一定的周期从server获取为当前工作区所准备的策略，并按照策略的需要在工作区内部完成实施。当前SmartIDE已经实现了3个基础策略：

• 心跳策略：这是agent的默认策略，所有工作区都会实施这个策略，其功能非常简单，就是为server提供当前工作区的健康状态检查。工作区健康状态会显示在工作区详情页的右上角，如下图

• git-config策略：远程工作区需要与当前用户的身份进行绑定，在使用Git作为源代码管理工具的过程中，我们需要将用户的git配置注入到属于用户的工作区中，这样用户就可以在server上统一配置自己的git-config内容，确保自己所使用的所有的工作区均使用统一的git-config配置项。

• ssh-key策略：ssh-key作为一种通用的身份认证机制，广泛用于各种git服务或者服务器之间的认证。通过ssh-key策略，我们可以确保用户的工作区均使用统一管理的密钥进行服务间的授权，包括：SSH-GitUrl，SSH 远程登录等场景。本次ssh-key策略上线之后，SmartIDE也可以开始支持Git 私有仓库的常见操作。

工作区策略可以通过server管理界面进行配置，如下图

社区早鸟计划

如果你对云原生开发环境感兴趣，请扫描以下二维码加入我们的 SmartIDE社区早鸟计划

谢谢您对SmartIDE的关注，让我们一起成为云原生时代的 Smart开发者, 享受 开发从未如此简单 的快乐。

让我们一起成为 Smart开发者，享受开发如此简单的乐趣。

SmartIDE v0.1.18 已经发布 - 阿里OpenSumi采用SmartIDE插件市场提速10倍、Dapr和Jupyter支持、CLI k8s支持

阿里蚂蚁OpenSumi采用SmartIDE插件市场提速10倍

在 Sprint 16中，我们开始支持阿里蚂蚁开源的国产IDE开发框架 OpenSumi，并且在 Sprint 17 发布了 基于 Eclipse OpenVSX Registry 的 SmartIDE插件市场。OpenSumi的开发团队在测试了 SmartIDE插件市场之后发现速度提升可以达到10倍以上，并将其设置为OpenSumi内默认的插件市场来源。

下图来自：https://github.com/opensumi/core/pull/1045 ，是 OpenSumi 团队的测试结果。

SmartIDE插件市场 是我们针对国内使用类 VSCode IDE 的开发者提供的开源插件市场镜像服务，我们将 open-vsx.org 的国外站点通过 Github Action 自动同步到了部署在国内的站点中，经我们自己测试速度提升2-5倍。此次经阿里蚂蚁OpenSumi团队的测试结果提升10倍的原因可能是因为他们采用了批量插件安装的方式。这个结果对于国内使用类 VSCode IDE 的团队来说是一个好消息，说明我们提供的 SmartIDE插件市场 开始发挥它应有的作用了。

在 Sprint 18 中，我们还对插件同步机制进行了改进，增加了按周期自动同步和历史版本同步机制，这样就可以确保国内的小伙伴及时获取到最新的VSCode插件。

相关修改可以参考 https://github.com/SmartIDE/eclipse-openvsx/issues/2

以上PR已经在2022年5月18日合并进入OpenSumi的主分支，安装 OpenSumi 的最新版就已经可以体验插件极速安装的快感了。

• OpenSumi 官网地址 https://opensumi.com
• SmartIDE 插件市场地址 https://marketplace.smartide.cn/
• 类VSCode IDE更新插件市场教程 https://smartide.cn/zh/docs/manual/marketplace/config/

Dapr 微服务开发环境支持 VM-Like-Container验证通过

Dapr 是微软主导的云原生开源项目，2019年10月首次发布，到正式发布 V1.0 版本的不到一年的时间内，github star 数达到了 1.2万（现在已经超过1.7万星），超过同期的 kubernetes、istio、knative 等，发展势头迅猛，业界关注度非常高。

Dapr 这个词是是 「Distributed Application runtime」的首字母缩写，非常精炼的解释了 dapr 是什么：dapr 是一个为应用提供分布式能力的运行时。

Dapr官网 https://dapr.io

SmartIDE 团队 Sprint14 开源了包括 .net6 环境在内的开发者镜像相关代码，在那个时间点对于 .net6 技术栈的支持已经完整。这个迭代中，我们针对 .net6 的开发者镜像进行了改进，增加了 VM-Like-Container 的能力，以便可以完美支持 dapr 环境的搭建和调试。

所谓 VM-Like-Container，其实就是将容器当成虚拟机来使用。大家可能会觉得有点奇怪，既然我们都容器化了，为什么还要开倒车，回到VM呢？这个其实和开发者的需求有关，一般的容器都是为了运维环境优化，并没有考虑开发者的诉求，或者说这两者的诉求的相互冲突的，运维要的是稳定，因此极尽所能剥夺一切容器内不必要组件，而开发者需要灵活，需要能够在容器内按需构建自己的所需要的各种组件。比较典型的场景就是在容器中运行docker，也即是大家所说的 DIND (Docker in Docker) 的场景。对于开发者来说，确保应用可以用容器发布的最好方式就是在自己的开发环境中可以直接执行 docker build 和 docker run，这样才能确保自己所交付的代码是经过容器化环境测试的，不至于等到流水线打包并部署完成以后才发现自己的代码其实在容器中无法正确运行。

对于开发环境而言，提供内置的Docker环境意味这开发者有更加灵活的能力构建自己专属的定制化环境，比如运行各种类型的中间件、同时运行和调试应用的多个版本，临时组网进行测试等等。对于Dapr而言，dapr的开发工具需要使用docker环境来模拟微服务边车 (sidecar) 的很多能力，比如最常见的服务发现和消息队列，都需要dapr运行一些中间件来提供相关的服务。以下就是在 SmartIDE 的 .net6(vscode) 开发环境中，运行一个机遇dapr的示例应用的截图：

示例代码库地址：https://github.com/SmartIDE/sample-dapr-traffic-control

在这个示例中，我们使用了 dapr init 来初始化 dapr 开发环境，运行 dapr 的基础服务，然后启动 Mosquitto 作为 MQTT broker，RabbitMQ 作为消息队列以及其他的基础服务。应用本身需要至少4个微服务组件才能正常工作：

• TrafficControlService 是交通控制服务，也是主服务，其业务逻辑是根据公路上的2个固定位置摄像头反馈的数据，计算车辆通过摄像头的车速，以便判断是否存在超速行为。
• FineCollectionService 是罚单处理服务，根据 TrafficControlService 发送过来的车牌数据，查询车辆注册数据库（VehicleRegistrationService）获取联系人信息，并发送邮件
• VehicleRegistrationService 是车辆注册数据库，提供车辆信息查询，可以通过车牌号码获取车主信息，比如邮件地址。
• Simulation/VisualSimuation 是一个模拟器应用，用于模拟车辆行为，以便可以测试以上服务的工作情况，在上图中展示的是 VisualSimulation 的画面。

下面这个视频完整演示了如何使用 SmartIDE开发调试 经典的Dapr示例 dapr-traffice-control，相关的启动命令如下

smartide start https://github.com/SmartIDE/sample-dapr-traffic-control

Jupyter Notebook 环境支持

远程工作区 的一个重要优势就是可以帮助开发者更好的利用远程主机的强大算力和数据处理能力，在这个领域中 Jupyter Notebook 无疑是非常典型的应用类型。我们在 Sprint 18 中增加了对 Jupyter Notebook 的远程工作区支持，现在开发者可以使用一个简单的指令就可以启动预装 Jupyter Notebook 的远程工作区，并且通过 --host 参数将这个 工作区漫游 到任意主机或者k8s环境中。相关指令如下：

## 启动使用 Jupyter Notebook 的数据科学处理开发者容器
smartide new anaconda -T jupyter 
## 在远程主机上启动
### 首先将自己的主机添加到 SmartIDE工具中，并获取hostId
smartide host add <Ip-Address> --username <user> --password <pwd>
### 使用 --host 参数再次启动
smartide new --host <hostId> anaconda -T jupyter 

使用以上方式启动的 Jupyter Notebook 环境还会内置一个 VSCode WebIDE，这样可以利用内置的Git管理工具将制作好的 Notebook 提交到Git代码仓库中进行版本管理。 其他开发者就可以使用 smartide start <代码库地址> 指令一键将同样的环境漫游到自己的本地开发机，主机或者k8s上。

为了让大家更容易体验，我们为大家提供了一个预置了示例 Notebook 的代码库，这个示例中内置了一个新冠疫情数据分析Notebook。

示例地址 https://github.com/SmartIDE/sample-anaconda-jupyter

使用这个 Notebook 对上海和北京最近的疫情数据的分析结果如下：

备注：以上数据分析仅为展示SmartIDE的产品特性，数据处理的非常粗糙。欢迎对 Juypter Notebook 开发有兴趣的小伙伴提交PR改进我们的分析算法。

大家可以使用以下指令一键启动上面这个示例

## 在本地开发机上启动
smartide start https://github.com/SmartIDE/sample-anaconda-jupyter.git
## 在远程主机上启动
smartide start --host <hostId> https://github.com/SmartIDE/sample-anaconda-jupyter.git

启动以后的效果如下，图中：

1. SmartIDE简化指令方式 se = smartide
2. 内置在远程工作区中的 VSCode WebIDE，这个远程工作区中还预置了 Python 环境，开发者可以直接在VSCode中使用Python语言进行编程。
3. 内置在工作区中的 Jupyter Notebook，加载了 “新冠疫情分析” 示例数据，这个 Notebook 通过读取微信疫情小程序的API接口获取实时数据，并利用图表展示了上海过去60天疫情变化趋势

在适配 Jupyter Notebook 的过程中，SmartIDE没有修改一行产品代码，完全利用我们所提供的 IDE配置文件 和 开发者镜像模版库 的能力完成。SmartIDE作为一款面向企业的B端产品，对于可扩展性能力的要求是根植于产品的设计核心。利用这种能力，企业在部署了SmartIDE之后无需进行二次开发就可以自助适配各种开发语言，工具和环境，大幅降低企业采纳远程工作区的技术门槛和实施成本。

下面的视频展示了在 SmartIDE 中使用 Jupyter Notebook 分析上海和北京疫情数据的过程：

CLI k8s 模式支持（特性预览）

SmartIDE CLI中已经增加了k8s相关指令，用户现在可以使用 smartide start --k8s 来完成在k8s集群中启动 远程工作区 的操作，基于 计算器示例应用 的启动命令如下：

smartide start --k8s SmartIDEAKS --namespace default --repourl https://github.com/idcf-boat-house/boathouse-calculator.git --filepath .ide/k8s.ide.yaml

使用这个指令之前用户需要完成2个准备工作：

1. 在k8s集群上安装 smartide-file-storageclass，这个配置的目的是为了能够让 SmartIDE 可以支持各种类型的k8s服务。Storage Class （存储类定义）是k8s上适配不同提供商的底层存储driver而提供了一层隔离机制，在远程工作区场景下，我们需要允许工作区中的多个开发容器共享的访问同一份代码/配置/环境变量/工具等资源，因此需要使用具备 ReadWriteMany 能力的存储 driver。
2. 在本地的 .kube 目录中导入你的k8s集群的 kube-config 文件，这个步骤是为了允许 SmartIDE CLI 可以连接k8s进行操作的权限。

以下是导入 storageclass 的相关指令，当前只提供Azure微软云的配置文件，使用其他云平台或者自建k8s平台的小伙伴可以自行查找适合自己平台的StorageClass配置文件，后续我们也会统一提供。

kubectl apply -f https://smartidedl.blob.core.chinacloudapi.cn/kubectl/resources/smartide-file-storageclass.yaml

另外，如果使用 azure-cli，可以直接使用以下指令快速创建k8s集群（测试用途）并获取集群的 kube-config 配置

az login
az account set -s <订阅ID>
az group create --name <资源组名称> --location southeastasia
az aks create -g <资源组名称> -n <集群名称> --location southeastasia --node-vm-size Standard_DS2_v2 --node-count 1 --disable-rbac --generate-ssh-keys
az aks get-credentials -g <资源组名称> -n <集群名称>

CLI k8s 模式现在已经支持一键启动工作区和清除工作区操作，我们正在将这个cli能力集成到server中；在后续的迭代中大家会陆续获得 server k8s 模式的更新。

社区早鸟计划

如果你对云原生开发环境感兴趣，请扫描以下二维码加入我们的 SmartIDE社区早鸟计划

谢谢您对SmartIDE的关注，让我们一起成为云原生时代的 Smart开发者, 享受 开发从未如此简单 的快乐。

2022年5月19日

SmartIDE v0.1.17 已经发布 - 模版库远程模式和插件市场公测

SmartIDE v0.1.17 已经发布，本次同步更新了CLI (Build 3332) 的稳定版通道和Server (Build 3333) 生产环境（内测中）。请参考对应的 安装说明 获取最新版。在刚刚完成的Sprint 17中，我们主要完成以下特性。

• 模板库：对cli现有的 smartide new 指令进行了增强，支持针对远程主机使用 new 指令，用户只需要在 new 指令中增加host 参数即可在远程主机上使用模板库创建工作区。同时，我们已经将模版库集成到server中，用户可以使用网页的方式选择模版并创建工作区。

• 插件市场：针对开源项目Eclipse OpenVSX进行了中文汉化和中国本地部署，用户可以通过 https://marketplace.smartide.cn/ 访问位于北京数据中心的插件市场。这个插件市场支持VSCode, VSCodium, Code-Server, OpenVSCode Server, OpenSumi以及Eclipse Theia 使用。SmartIDE插件市场可以大幅提升以上IDE的插件安装速度（根据你自己的网络情况，提高2-5X），并且支持企业内网本地部署，为研发企业内部针对类VSCode的IDE提供安全可控的插件管理机制提供可能。

模板库

SmartIDE CLI 原有的模板库功能允许用户通过一个简单的指令 smartide new 就可以一键创建基于7种技术栈和4种IDE的容器化 工作区，这个功能原来只能在开发者本机使用，无法支持远程服务器。在Sprint 17 中我们针对这个功能进行了增强。允许用户直接在指定的远程服务器上新建工作区，同时将这个功能集成到了 Server 中，允许用户通过网页完成基于模版的工作区创建。

在Server中使用模版库

SmartIDE Server 是一款开源的容器化工作区管理工具，你可以在任何可以运行Docker和Kubernetes的环境中自行部署。在Sprint 17中，我们将模板库功能引入到Server中，允许用户通过网页选择模版并一键完成部署。

以下是使用Server版模板库功能创建 若依微服务版本 快速开发框架的演示视频，若依微服务版的模版包含 vue.js 的前端应用，一系列 Java Spring 后端服务，Nacos 服务注册中心，redis 缓存和 mysql 数据库（配置phpMyAdmin 管理工具）以及 SonaQube 代码检查工具；这是一个相对复杂的工作区，使用server版的模板库开发者可以一键创建以上所有环境，无需关心这些组件之间的配置，所有这些配置都已经预先设置好并保存在 IDE配置文件 中了。

使用new指令创建远程工作区

使用远程new指令创建工作区的操作如下

## 首先使用 smartide host 指令添加主机
smartide host add <主机IP或者域名> --username <用户名> --password <密码> [--port <SSH端口号，默认22>]
## 使用 smartide new 指令在指定的主机上创建工作区
smartide new --host <HostId> <模版名称> --type <子类型名称> --workspacename <工作名称>
## 如果在本地的当前目录中创建工作，则可以省略host和workspaceName参数
## type参数也可以省略，则可以使用当前默认模版
smartide new <模版名称> --type <子类型名称>

当前支持的模版列表如下，列表中的所有组合都可以通过以上指令用于在远程主机上创建工作区

以上所有模版以及模版所使用的开发者镜像(Dockerfile和相关代码、脚本)均开源提供给社区，具体可以参考以下链接

• 官网文档 镜像和模版
• 开源地址
  • https://gitee.com/smartide
  • https://github.com/smartide

插件市场

VSCode以及类VSCode IDE（包括：VSCodium, Code-Server, OpenSumi 和 Eclipse Theia）都使用国外的插件市场 open-vsx.org 作为数据来源。对于国内的开发者来说，因为网络原因造成插件安装缓慢或者安装失败的情况经常出现。同时，在很多企业内部，开发者也在大量使用VSCode作为自己的主力开发工具，由于安全管控的原因，企业内部的开发者往往无法访问外部互联网，开发者为了绕过企业的安全性管控会自行下载、复制和导入未经企业审核的VSCode插件进入企业受管控网络使用，这些做法会对企业的信息安全造成很大威胁。

为了解决以上这些痛点问题，SmartIDE针对 open-vsx.org 进行了汉化并进行了中国本地化部署。现在开始，开发者可以访问位于国内数据中心的 SmartIDE插件市场 ，并按我们官网文档中的方式修改自己 VSCode 中的 product.js 配置文件，即可使用 SmartIDE插件市场 安装插件，根据我们的测试，通过我们提供的插件市场安装插件可以获取至少2-5X的速度提升。

SmartIDE 插件市场地址 https://marketplace.smartide.cn/

product.js 文件配置如下，具体请见 SmartIDE 插件市场文档

"extensionsGallery": {
    "serviceUrl": "https://marketplace.smartide.cn/vscode/gallery",
    "itemUrl": "https://marketplace.smartide.cn/vscode/item"
}

"linkProtectionTrustedDomains": [
    "https://marketplace.smartide.cn"
]

以下视频是使用VSCodium分别从 Eclipse OpenVSX 和 SmartIDE插件市场 下载插件的速度比较，根据网络状况不同，可以提速2-5倍甚至更多。

SmartIDE插件市场的代码以及部署文档开源免费（EPL-2.0）提供给社区，并且我们为其企业提供私有部署技术支持服务。相关文档如下：

• SmartIDE插件市场概述
• 开源地址
  • https://github.com/SmartIDE/eclipse-openvsx
  • https://gitee.com/SmartIDE/eclipse-openvsx
• 如何更新Visual Studio Code以及兼容IDE的配置文件连接到SmartIDE 插件市场，包括：VSCode, Codium, Code Server, OpenVSCode Server和OpenSumi
• 部署手册

说明：Eclipse OpenVSX 是Eclipse基金会旗下的一款采用EPL-2.0开源授权的开源软件，按照 Github官网 上的说法：OpenVSX提供了一个 Visual Studio Marketplace 的替代品，包括可用于管理VSCode插件的数据库以及对应的Web应用，同时提供了一个cli工具用于后台管理。Eclipse OpenVSX出现的原因是微软并不允许类 VSCode IDE (VSCode的Fork) 使用官方的插件市场，因此社区需要一个类似的基础设施服务，具体可以参考这个 Issue 。

SmartIDE插件市场是OpenVSX的一个fork，我们在OpenVSX的基础上进行一些修改以便适合中国开发者使用，包括：界面的中文汉化，插件自动同步到国内（使用GitHub Action），针对国内部署进行验证，测试以及服务托管。因此，SmartIDE插件市场是 Eclipse OpenVSX 的一个代理服务，目的是方便国内的开发者安装和管理VSCode的插件。同时，也支持企业使用SmartIDE插件市场进行私有部署。当然，我们也欢迎国内的开发者直接将自己的插件发布到我们所运行的 SmartIDE插件市场，如果你有类似的需求，请和我们联系。

社区早鸟计划

如果你对云原生开发环境感兴趣，请扫描以下二维码加入我们的 SmartIDE社区早鸟计划

谢谢您对SmartIDE的关注，让我们一起成为云原生时代的 Smart开发者, 享受 开发从未如此简单 的快乐。

2022年5月7日

SmartIDE v0.1.16 已经发布 - 支持阿里&蚂蚁开源的国产 IDE OpenSumi

SmartIDE v0.1.16 (Build 3137) 已经在2022年4月19日发布到稳定版通道，我们在这个版本中增加了阿里和蚂蚁发布的国产IDE OpenSumi的支持，以及其他一些改进。SmartIDE 从 Sprint 11 (v0.1.11) 开始已经将重心转向 Server版 的开发，并且已经针对社区开放了server的内测。但是对于 CLI 的改进和增强一直没有停止，因为 CLI 是 SmartIDE 的核心，实际上我们的 Server 版对于 工作区 的管理也是通过云原生开源流水线框架 Tekton 调度 CLI 实现的。

我们将在近期发布更加完善的 Server 版安装部署手册和文档，同时 Server 版 和 CLI 核心代码也将在近期开源。SmartIDE 的核心代码将采用GPL协议开源，允许任何组织和个人免费使用我们的代码搭建自己的云原生IDE环境。

OpenSumi 简介

严格来说，阿里的 OpenSumi 并不是一个IDE产品，而是一个IDE二次开发框架。这个定位与 Eclipse Cheia 的定位相同。SmartIDE 的早期版本也支持 Eclipse Theia，但是由于其操作体验与VSCode还是存在一定的差距，后续我们将重心转向类VSCode的IDE支持，比如对 OpenVSCode Server 的支持，以及 JetBrains 系列IDE全家桶的支持。阿里&蚂蚁的开发团队在2022年3月3日发布了OpenSumi以后，SmartIDE团队对这款IDE进行了研究，认为可以替代Eclipse Theia 作为未来提供 “定制化IDE” 解决方案的基座，因此将重心转向了对 OpenSumi的支持，按照阿里&蚂蚁相关文章的说明：

“OpenSumi 是一款面向垂直领域，低门槛、高性能、高定制性的双端（Web 及 Electron）IDE 研发框架，基于 TypeScript+React 进行编码，实现了包含资源管理器、编辑器、调试、Git 面板、搜索⾯板等核新功能模块。开发者只要基于起步项目进行简单配置，就可以快速搭建属于自己的本地或云端 IDE 产品。” – 原文链接

OpenSumi 当前已经在阿里内部广泛应用在很多场景，具这篇 云原生架构下蚂蚁 Cloud IDE 的应用实践 的文章显示，阿里内部的的很多研发相关的方案都有在IDE中的落地场景，比如：

云测平台集成在IDE中的手机测试环境

代码平台中直接在IDE中提交PR进行代码评审

新人培训和入职测试场景

定制化IDE解决方案

随着软件在我们日常生活中的广泛应用，软件开发不再会是一个特定的职业而会变成一种生存技能。就如同驾驶汽车的技能一样，在汽车刚刚出现的时候，驾驶汽车一度都是一项专业技能，司机也是一个专门的职业，而随着汽车逐步演变成了我们的生活交通的普遍手段，司机也从一个职业变成一种特定的生活技能。

对于软件开发工具而言，它也会从一个只有专业人员才能掌握的工具变成每个人都需要的日常工具。但是软件和汽车还有一个本质区别，就是汽车仅仅是一种交通工具、是单一行业；而软件则是各行各业都需要的基本组成部分，这个特性必将推进软件开发工具（IDE）向着专业化定制化的方向发展，需要根据不同行业的特点提供针对性的快速开发特性，以便降低软件提供者的门槛，提高交付效率和质量。这一点上，在很多的大型软件开发团队中早已有所体现，比如很多大型银行都在Eclipse的基础上定制开发了自己的开发框架和工具集，并在企业内部作为开发规范进行推广，因为这样可以帮助他们的开发人员提高工作效率，减少重复劳动，规范交付过程；再比如微软内部的DevDiv，就是专门定位于帮助微软的软件开发团队（比如：Windows, Office, XBox等）提供开发工具的专业化团队，其产品Visual Studio, Visual Studio Code 和 Azure DevOps 都是专业化IDE的业界天花板。这些案例都说明，专业的软件开发团队需要定制化的专业工具才能保证交付效率。

IDE 产品的研发一直以来都是一件门槛高、费时费力的事情，OpenSumi 通过开源 OpenSumi 帮助对 IDE 有兴趣的开发者更好地了解并掌握 IDE 研发这项技术，让更多的开发者可以以一种低门槛的方式去研发自己的 IDE 产品。OpenSumi 也从几个方面提供了很好发展路线图，比如：高度可定制的UI，完全开放的插件体系，对VSCode API适配的完整计划以及兼容VSCode Extension的特性。这些都将为定制化IDE解决方案提供必要的支撑，比如可以开发出类似下图这样的可视化开发场景。

SmartIDE专注于云原生容器化工作区的管理和调度，我们的目标就是支持各类开发者使用的IDE，OpenSumi符合SmartIDE的IDE生态定位。相信随着SmartIDE和OpenSumi的进一步成熟，会为开发者，特别是中国开发者带来更高效的云原生开发新体验！

使用 SmartIDE 启动 OpenSumi WebIDE

OpenSumi的定位非常符合SmartIDE对IDE定制化解决方案的需求，因此我们针对OpenSumi进行了适配和集成，开发者可以使用一个非常简单的指令即可在浏览器中启动一个基于OpenSumi WebIDE 的 node.js 开发环境，具体请参考 Node快速启动 文档。SmartIDE支持7种主流技术栈，包括：JavaScript/Node.js，Java ，DotNet，Python ，PHP，Go语言和C/C++，并且支持在Windows/MacOS/Linux上跨平台使用，此次扩展了IDE支持后，将我们所支持的IDE也扩展到3大体系，分别是：VSCode，JetBrains和OpenSumi。

快速启动OpenSumi的Node.js开发环境指令如下

## 使用OpenSumi WebIDE开启Node开发环境
smartide new node -T opensumi

以下是处于单步调试状态的 OpenSumi WebIDE

或者也可以通过我们的 计算器 示例应用体验使用OpenSumi开发调试Node.js应用的过程：

## 使用OpenSumi调试计算器示例
smartide start https://gitee.com/idcf-boat-house/boathouse-calculator.git --filepath .ide/opensumi.ide.yaml

以下是正在单步调试 计算器示例应用 的OpenSumi WebIDE，B站视频

相关链接：

• 兼容 VS Code 插件！阿里&蚂蚁联合开源国内首个强定制 IDE 研发框架 OpenSumi
• 云原生架构下蚂蚁 Cloud IDE 的应用实践
• OpenSumi 官网
• 文档 - 镜像与模版
• 文档 - SmartIDE Server 版快速开始
• 文档 - SmartIDE CLI 快速开始
• 文档 - Node.JS 快速开始

社区早鸟计划

如果你对云原生开发环境感兴趣，请扫描一下二维码加入我们的 SmartIDE社区早鸟计划

谢谢您对SmartIDE的关注，让我们一起成为云原生时代的 Smart开发者, 享受 开发从未如此简单 的快乐。

2022年4月19日

SmartIDE Sprint 14 Server版内测 (v0.1.14)

在过去的3个迭代中，SmartIDE开发团队完成了Server内测版本的开发，当前的Server版已经可以支持开发者自助添加Linux主机并使用这些主机资源作为自己的开发环境进行应用开发调试，所有的环境通过开发者镜像提供并全部采用容器的方式运行。为了配合以上场景的实现，我们这次终于发布了Linux版本的cli工具，因为Server版的主机调度就是通过这个linux版本的cli进行的，因此我们可以确保这个cli是经过测试并且可以在常见场景下可靠运行。同时，我们还完成了全部 SmartIDE开发者镜像 的构建工作，当前已经发布了 node/javascript/前端、java、python、dotNet、golang、php、c/c++ 这7个主流技术栈的相关镜像的构建和发布，而且每一种技术栈都提供了SDK-Only、VSCode WebIDE 和 JetBrains WebIDE 3类不同用途的镜像方便开发者选择使用。

Server内测

2021年12月3日，SmartIDE 发布了第一个社区可用的版本，那个时候的SmartIDE是以一款命令行工具（cli）的形式出现的。我们之所以先以命令行工具的方式提供SmartIDE的功能，是因为cli本身承载了SmartIDE的核心功能：工作区调度。cli的发布让开发者可以在不了解容器技术，无需学习docker指令以及k8s的工作机制的前提下，一键完成 SmartIDE工作区 的部署，而且在工作区中可以内嵌自己喜欢的WebIDE（VSCode或者JetBrains全家桶）。cli的发布给开发者提供了极大的便利，使得以前必须要专业运维人员才能完成的复杂环境搭建工作都可以非常方便地自助完成。

当然，cli也有它的缺点，就是用户体验不好，操作门槛高。用户必须充分了解cli的各种指令和参数才能顺利地完成工作区的创建和管理；因此我们在cli的功能相对稳定之后便开始着手进行Server版的开发。

SmartIDE Server 作为 SmartIDE 企业版功能的基座，为用户提供简单直观的操作界面，进一步降低SmartIDE/云原生开发的门槛。

下图：使用Server一键创建工作区

下图：工作区启动后的详情页以及正在使用中的JetBrains IntelliJ IDEA WebIDE (Projector)，同时打开的还有集成在工作区中的 phpMyAdmin 工具。

内测邀请方式

如果您对 SmartIDE Server 有兴趣，可以扫描以下二维码，添加“小S”微信，加入SmartIDE早鸟计划后即可获得内测机会。

Linux 版 SmartIDE CLI 工具

从SmartIDE发布以来，一直都有小伙伴希望直接在Linux主机上运行我们的 cli 工具，在这次的发布中我们已经将 Linux 版本的安装脚本更新在了官网上，大家可以通过 安装文档 获取安装脚本

请注意：在获取安装脚本的时候注意选择 Linux 标签页，Linux版本同样提供稳定版和每日构建版两个通道。

Linux版本安装和运行效果如下

开发者镜像和模版库开源

为了能够让大多数开发者都可以享受到SmartIDE带来的便捷，SmartIDE 提供了 主流开发语言的SDK 的容器镜像，包括 node/javascript、java、golang、python、dotnet/C#、php、C/C++，并且集成了VSCode和JetBrains两大主流IDE体系。开发者可以直接使用这些镜像作为自己的通用开发环境，或者以这些镜像为基础来构建自己专属的开发镜像。

SmartIDE所提供的开发者容器镜像中已经针对开发调试和测试场景进行了一系列的优化，使用SmartIDE的开发者镜像会有一系列的好处，比如：非root用户运行 和 内置SSH服务支持。

为了同时兼顾国内和国外开发者使用，所有SmartIDE的镜像同时托管至阿里云和Docker Hub，方便开发者根据自己的地理位置选择最快速的拉取地址：

• 国内阿里云地址：registry.cn-hangzhou.aliyuncs.com/smartide/<镜像名称:TAG>
• 国外 Docker Hub 地址：registry.hub.docker.com/smartide/<镜像名称:TAG>

我们在 SmartIDE CLI 中内置了IDE模版功能，开发者可以使用 smartide new 指令获取所有可用的模版，这些模版与以上的开发者镜像一一对应，可以用来一键创建标准化的开发环境。

SmartIDE模版库本身是开源的，地址为

• 国内Gitee: https://gitee.com/smartide/smartide-templates
• 国外GitHub: https://github.com/smartide/smartide-templates

使用模版库开发者可以一键创建自己需要的IDE开发环境，比如：

#########################################
# Node/JavaScript 前端技术栈
#########################################

## 创建带有node全版本sdk的开发容器，无IDE，可通过VSCode SSH Remote或者JetBrains Gateway接入
smartide new node
## 创建带有node全版本sdk的开发容器，使用VSCode WebIDE
smartide new node -T vscode
## 创建带有node全版本sdk的开发容器，使用JetBrains WebStorm WebIDE
smartide new node -T webstorm

我们这次发布了覆盖7个主流技术栈的SDK-Only, VSCode 和 JetBrains IDE开发者镜像一共22个，您可以通过 镜像和模版 文档获取详细列表，包括其对应的 docker pull指令和smartide new指令。

SmartIDE Sprint 9 (v0.1.9)

在过去的Sprint 8 和 Spring 9 中，我们进一步加强了当前的SmartIDE CLI组件的稳定性和易用性，同时启动了k8s环境部署能力的开发和SmartIDE Server的总体架构设计以及调度引擎的核心能力开发。另外，我们也在本次迭代中发布了对JetBrain全家桶系列中的IntelliJ IDEA, Rider和Goland三种c

关键特性说明

稳定性和体验增强

• 环境变量注入逻辑优化
  • #622 修复环境变量注入过程中互相覆盖的问题，确保所有环境变量均可以正常注入
• Vol映射逻辑优化：
  • #644 动态监测本地路径并替换成绝对路径，避免某些情况下因为相对路经造成的vol映射失败问题
  • #647 Windows远程模式下因为路径拼接问题启动失败
• 状态管理优化：
  • #641 改进了在用户手工删除工作区目录后再执行remove/reset操作无法删除记录的问题(Github Issue #18)
  • #636 reset -ya 命令中文字提示问题
• 体验增强
  • #649 提供短小命令集 ls | rm | v
  • #645 启动指令简化， 提供 smartide start 一键启动方式，自动完成git clone动作然后自动执行 smartide start

k8s start

• k8s start 个人开发者版
  • #616 允许用户使用 smartide start –k8s 的方式完成 dev-container 在所指定的K8s集群中的部署，代码拉取和端口转发动作；开发者仍然可以通过类似 http://localhost:6800 的方式访问部署在k8s pod中的WebIDE

SmartIDE Images 体系

• JetBrain Projector 可用镜像
  • #612 制作 JetBrain IDEA, Rider 和 Goland 镜像
• Image V2 体系开发
  • #567 Image V2 镜像体系开发，完成V2镜像体系规划，采用三层镜像体系：base-sdk-IDE；本迭代完成了 smartide-base-v2, smartide-node-v2, smartide-node-v2-vscode 的镜像交付

Smart IDE Server 架构设计和基础能力开发

• #618 使用tekton流水线任务封装smartide-cli，为Server核心调度引擎提供基础

SmartIDE Image V2

SmartIDE的核心能力是容器化开发环境，因此对容器镜像的优化是我们一直努力的方向。虽然Docker技术从2013年就开始在全球普及，Docker Hub上也有数亿的镜像可供大家使用，但是绝大多数镜像都没有为开发调试环境进行优化，当然这和容器化技术在之前主要被用于运维领域有很大关系，换句话说，容器化技术对于开发者的潜能其实并没有被充分挖掘。SmartIDE Image 的设计就是为了让容器化技术为开发者服务，解决我们在开发调试过程中的各种痛点和难题。

因此，SmartIDE Image 的设计目标是：通过合理利用容器化技术，为开发者提供统一、标准化、满足开发调试测试需求的镜像，在这个目标之下，我们将镜像分成3个层次

• L0 - Base镜像提供基础能力，比如：认证，权限，SSH；使用Ubuntu满足日常开发基础组件的需求
• L1 - SDK镜像提供开发语言环境支持能力，同时提供SDK Only的使用方式，允许本地IDE将SDK镜像作为开发环境直接使用，不嵌入WebIDE
• L2 - WebIDE镜像，在SDK镜像的基础上嵌入常用的IDE，主要支持3大体系
  • VSCode
  • JetBrain Projector
  • Eclipse Theia

这些容器镜像不仅SmartIDE可以使用，开发者如果对Docker的操作比较熟悉，也可以直接使用Docker和Docker-Compose工具来直接使用这些镜像，榆次你我们未来会在GitHub/Gitee上开源这些镜像，支持开发者在不使用SmartIDE的情况下直接使用镜像作为自己的开发环境。

SmartIDE Server 设计目标

SmartIDE产品的核心理念就是让开发者具备云原生的超能力，同时又不必学习复杂的云原生知识。”把复杂留给自己，把简单给到开发者“ 就是这个理念最好的总结，也因此我们的口号就是 【Be a Smart Developer 开发从未如此简单】。未来我们即将发布的SmartIDE Server也将延续这个理念，确保以下设计目标得一体现：

• 基本能力
  • 允许开发者自行注册资源作为SmartIDE的调度目标，包括：主机和k8s集群
• 独立开发者/团队版
  • 允许开发者自行一键部署：smartide server install 指令集
  • 支持单机、VM集群、k8s集群三种部署模式；最大化降低开发者自行部署SmartIDE Server的难度，做到任何人都能部署（无需专业运维人员，无需专业运维知识也能部署）
• 企业版
  • 认证体系集成
  • 支持多团队，多集群管理
  • 私有模板库
  • 私有镜像仓库，企业定制版SmartIDE Images

我们相信，具备了这些能力的SmartIDE一定可以助力开发者最大化利用云的价值，成为具备超能力的开发者，一个人搞定以往需要一队人才能搞定的工作。

2021.1.4 徐磊于北京

SmartIDE 产品发布 (v0.1.7)

在经过了7个迭代以后，SmartIDE终于对外正式发布了，我们在2021年12月2日通过【冬哥有话说】栏目进行了一场产品发布会，正式对外公布了SmartIDE当前的功能、产品规划路线图以及后期推广计划。发布会本身非常成功，有超过2000人通过B站直播间直接参与了整个直播，整个直播持续了2个小时，有超过1500人坚持到最后。我们在发布会之前1周投放在B站上的产品介绍视频【SmartIDE - 开发从未如此简单】获得了超过1.4万的点击率并为我们的B站渠道收获了超过200名粉丝。

以下是这次发布会的视频录制

SmartIDE的三种模式

在发布会上，我们公布了SmartIDE的三种主要形态，包括：本地模式，远程主机模式和k8s模式。

• 本地模式: 本地模式通过一个简单的 smartide start 命令，根据嵌入在代码库中的环境说明文件(.ide.yaml)完成环境的启动，让开发者可以无需搭建任何开发环境，即可通过容器的方式开始编码调试以及基本的源代码管理(Git)操作，同时在这个环境中还嵌入了一个WebIDE。
• 远程主机模式: 远程主机模式允许用户在 smartide start 命令中增加 –host 参数直接调度一台远程Linux完成开发环境的启动。相对于本地模式，远程主机模式更能够体现SmartIDE的能力，开发者可以利用远程主机更为强大的算力，更庞大的存储以及更高速的网络获取更好的开发体验，还可以完成一些本地模式下无法完成的开发操作，比如：AI和大数据开发，大型微服务项目的开发等等。SmartIDE对于开发者使用的远程主机没有任何限制，只需要开发者可以通过SSH方式访问主机即可，远程主机可以位于任何位置，包括：公有云，私有云，企业数据中心甚至开发者自己家里。
• k8s模式: 将远程主机模式命令中的 –host 替换成 –k8s，开发者即可将开发环境一键部署到 Kubernetes (k8s) 集群中。与远程主机模式一样，SmartIDE对于开发者所使用的k8s集群没有任何限制，无论是公有云托管式集群，还是自行部署的集群均可。只要开发者对于某个namespace具备部署权限，即可通过SmartIDE完成开发环境的一键部署。k8s模式将为开发者开辟一个全新的天地，借助k8s所提供的高度灵活高效的环境调度能力，我们可以为开发者提供更加丰富的使用场景和更为强大的开发环境支持。

路线图

在发布会上，我们同时公布了SmartIDE未来发展的路线图，从当前我们所提供的 smartide-cli(命令行工具) 应用将贯穿未来的整个路线图，作为开发者与开发工作区(Workspace)之间进行交互的主要桥梁，在此基础上我们也将为开发者提供更加易于使用的图形化工具，包括桌面版SmartIDE工具和Web开发者门户。这些全新的能力将协助开发者完成更为复杂的环境调度和团队协作场景。SmartIDE针对独立开发者和中小团队的功能将采用开源免费的方式提供，针对企业的版本则会提供企业授权和更为完善的产品技术支持。

社区推广计划

同时我们还公布了后续的2项社区推广计划：

• Smart Meetup: 我们将通过【冬哥有话说】每周推介一款好用的开源代码库给到大家，整个推介过程控制在15分钟内，全程通过演示的方式完成，期间将使用SmartIDE来启动开源代码库的编码调试，让开发者在了解了开源项目本身的价值的同时了解SmartIDE带来的快速便捷开发体验。
• Smart早鸟计划: 我们将持续的在社区中招募希望提前体验SmartIDE的开发者，加入我们的微信群。作为一款由开发者为开发者打造的开发工具，我们希望听取真正使用者的意见，持续改进我们的产品，和开发者一起将这个产品打造成开发者手中的利剑。

v0.1.7发布说明

我们本次还同时发布了了v0.1.7版本的 smartide-cli 工具，其中包括了以下主要能力和功能改进：

状态管理能力

开发者的工都不是连续的，我们经常需要在受到打扰之后快速恢复工作状态或者在多个项目中进行切换。为此，我们提供了以下命令为开发者提供快速恢复工作状态的能力。

# 获取所有启动过的环境列表
smartide list
# 使用以上列表中的工作区Id(WorkspaceId)一键恢复现有工作区状态
smartide start <WorkspaceId>
# 停止/删除/清理现有工作区
smartide stop|remove <WorksapceId>

smartide new 模板库

为了方便开发者从零开始SmartIDE进行项目，我们提供了以下命令帮助开发者一键启动空白项目或者已经初始化好的项目模板

# 获取当前所有可用的项目模板
smartide new
v0.1.7.1456
SmartIDE工作区模板
TemplateType TypeName
node         _default
node         express
node         base
java         _default
golang       _default
php          _default

选项：
  -d, --debug         是否开启Debug模式，在该模式下将显示更多的日志信息
  -h, --help          help for new
  -T, --type string   类型

# 示例，一键创建 node express 项目
smartide new node -T express

SmartIDE所使用的项目模板全部采用开源方式公布在GitHub上，同时为了方便开发者使用，我们还提供了gitee的镜像。

• https://github.com/SmartIDE/smartide-templates
• https://gitee.com/smartide/smartide-templates

更加详细的smartide new模板操作方式请参考：node.js快速启动手册

Linux的Docker一件安装脚本

为了方便开发者快速初始化自己的远程linux主机为SmartIDE使用，我们提供了安装脚本可以一键完成 docker 和 docker-compose 的安装配置，确保开发者可以顺利使用SmartIDE调度这台Linux主机，具体内容请参考：Docker & Docker-Compose 安装手册 (Linux服务器)

以上就是v0.1.7的主要功能，我们下个版本见。

SmartIDE v0.1.5 发布说明

首先说明一下版本号的变更，你也许注意到了我们的版本号从v0.1.2直接跳到了v0.1.5，这是因为我们决定使用第三位代表我们的迭代号，所以 v0.1.5 代表这是 sprint 5 的交付版本。我们在 sprint 4 中完善了 SmartIDE 的分支策略和流水线，为了能够更为直观，我们决定将第三位版本号用来跟踪迭代。后续我也会专门提供一篇博客来说明 SmartIDE 团队是如何管理我们自己的敏捷开发流程和环境的。

在刚刚结束的Sprint 5中，我们着重对 SmartIDE 的远程主机模式进行了一系列的改进，让远程主机模式进入可用状态，以下是Sprint 5所交付特性的列表：

• 完善远程主机连接方式：允许用户选择用户名密码或者SSH密钥两种方式连接到远程主机
• SSH密钥同步：允许用户将本地的SSH密钥同步到远程主机上，省去用户重新设置SSH密钥的步骤
• Git URL改进：允许用户通过https/SSH两种GitURL连接到自己的Git仓库，同时完善了私有Git库的支持（用户名密码和SSH两种认证方式都已经得到支持）
• CLI日志输出格式优化：添加时间戳并且优化英文输出内容
• 支持独立的docker-compose文件：允许用户使用独立的docker-compose.yaml文件，让.ide.yaml文件更加干净清晰

关键特性说明

完善远程主机模式使用场景

远程主机方式（smartide vm start）方式允许用户使用任何的远程Linux主机作为IDE运行环境，通过一个命令（smartide vm start）完成IDE在远程主机上的启动。远程主机方式可以让开发者不必受限于本地开发机的资源，使用位于数据中心，私有云或者公有云上的任何远程主机作为自己的开发环境；这种开发模式有以下优势：

• 远程资源本地化：开发人员不必受限于本地开发机的资源（CPU，内存，网络），可以利用任何网络主机作为自己的开发环境。
• 本地开发体验：在远程主机上运行的开发环境如果有任何端口需要被访问，开发人员都可以通过 localhost:port 方式访问到，smartide会在后台处理所有复杂的端口转发动作，开发人员无需关心中间的网络设置，也无需在远程主机上关闭防火墙或者设置云平台的网络设置。
• 配置简单：开发人员只需要对远程主机具备SSH访问权限（密码或者公私钥方式均可），就可以将远程主机编程自己的开发机
• 无需安装开发环境：所有开发环境全部通过容器镜像获取，开发人员不必再远程主机上安装任何环境（唯一需要的是docker和docker-compose工具需要安装好）

在Sprint 5中，我们针对远程主机模式进行了以下改进；

1. 支持使用用户名密码和ssh公私钥两种方式登录远程主机

##用户名密码认证方式
smartide vm start --host <主机IP或者域名> --username <SSH用户名> --password <SSH密码> --repourl <Git Repo 地址>
##SSH公私钥方式
### 这种方式需要开发人员首先将远程主机设置为可以使用本地默认SSH私钥（～/.ssh/目录）登录的方式
smartide vm start --host <主机IP或者域名> --username <SSH用户名> --repourl <Git Repo 地址>

2. repoURL 支持 http/https/ssh 3种方式

## Http/https 方式
--repoURL https://github.com/idcf-boat-house/boathouse-calculator.git
## SSH方式
### 这种方式需要首先在你的git服务上登记自己本地的默认SSH密钥（～/.ssh/目录）
--repoURL git@github.com:idcf-boat-house/boathouse-calculator.git

3. 以上登录方式和repourl格式可以混用

比如你可以使用用户名密码登录的同时使用ssh的GitURL，或者在使用ssh登录远程主机的同时使用http/https格式的GitURL。

4. 同步本地~/.ssh/目录内容到远程主机

为了避免在远程主机上再次设置自己的ssh密钥，我们会在提示用户之后将本地~/.ssh/目录内容同步到远程主机的~/.ssh/目录。开发者在使用远程主机的时候就不必再次生成SSH密钥并到git服务器上去进行登记。

5. 自动端口转发

下图所展示的是我正在使用SmartIDE编写本文档的现场截图，图中所标注的几个关键点解释如下：

• 1）在远程主机的开发环境中启动了 hugo server 并且运行在 1313 端口上
• 2）SmartIDE 本地驻守程序自动完成远程主机上的1313端口到本地1313端口的转发动作，同时转发的还有WebIDE所使用的3000端口，被转发到了本地的6800端口
• 3）通过 http://localhost:6800 可以直接访问远程主机上的 WebIDE
• 4）通过 http://localhost:1313 可以直接访问远程主机上的 hugo server

说明：Hugo 是一个用Go语言实现的静态站点生成器，你当前所浏览的 smartide.dev 站点所使用的就是hugo。我在使用hugo进行 smartide.dev 开发的过程中遇到了一个很麻烦的问题：git submodule恢复的问题，因为hugo通过git submodule的方式引入了大量GitHub代码库，在我本地环境中获取这些资源非常的缓慢。通过SmartIDE的远程主机模式，我可以使用一台云中的主机，这样我的git submodule获取时间可以从20-30分钟（本地模式）减少到2分钟（远程主机模式）。

以上就是Sprint5所发布版本的特性描述，我们2周后再见。

徐磊 2021.11.05于北京

SmartIDE v0.1.2 发布说明

各位开发者，大家好。在2021年10月24日程序员节这一天，SmartIDE的第一个公开发行版 v0.1.2 终于对外发布，我们并没有特意选择这个日子，但是冥冥之中我们的代码就把我们推送到了这个日子和大家见面，难道SmartIDE的代码是有生命的？

既然SmartIDE的代码是如此的懂得开发者，那么就让我们来认识一下这位新朋友。到底SmartIDE是谁？她能做些什么？

“人如其名”，SmartIDE是一个Smart的IDE（智能化集成开发环境）。你可能在想：好吧，又是一个新的IDE，我已经有了vscode/jetbrain全家桶，为什么我还需要另外一个IDE？

我们为什么要开发SmartIDE？

在当今这个软件吞噬世界的时代，每一家公司都是一家软件公司 … …

如今，软件确实已经深入我们生活的方方面面，没有软件你甚至无法点餐，无法购物，无法交水电费；我们生活的每一个环节都已经被软件包裹。在这些软件的背后是云计算，大数据和人工智能等等各种高新科技；这些现代IT基础设施在过去的5年左右获得了非常显著的发展，我们每个人都是这些高科技成果的受益者 … … 但是，为你提供这些高科技成果的开发者们自己所使用的软件（开发工具）却仍然像 “刀耕火种” 一般落后。

你可能会觉得这是危言耸听，那么让我来举一个简单的例子：大家一定都通过微信给自己的朋友发送过图片，这个过程非常简单，拿出手机，拍照，打开微信点击发送图片，完成。收到图片的朋友直接打开就可以看到你拍摄的照片了。但是对于开发者来说，如果要将一份代码快照发送给另外一位开发者，那么对方可能要用上几天的时间才能看到这份代码运行的样子。作为普通人，你恐怕无法理解这是为什么，如果你是一名开发者，你一定知道我在说什么！当然，我们也不指望普通人能够理解我们，对么？

这样的场景是不是很熟悉？开发环境的搭建对于开发者来说理所当然的是要占用大量时间和精力的，但是对于 “产品经理/领导/老板/老婆/老妈/朋友” 来说，开始写代码就应该像打开Word写个文档一样简单，只有开发者自己知道这其实很不简单。

但是开发者已经有了非常好用的IDE了，Visual Studio Code, JetBrain全家桶都已经非常成熟，并不需要另外一个IDE了。确实，SmartIDE也并不是另外一个IDE，我们不会重新造轮子，我们只是希望你的轮子可以转的更快、更高效、更简单。

如果我们可以

git clone https://github.com/idcf-boat-house/boathouse-calculator.git
cd boathouse-calculator
smartide start

然后就可以进行开发和调试，是不是很爽？

图中重点：

• 通过右下角的的终端，你可以看到仅用一个简单的命令（smartide start）就完成了开发环境的搭建
• 在右上角的浏览器中运行着一个大家熟悉的Visual Studio Code，并且已经进入了单步调试状态，可以通过鼠标悬停在变量上就获取变量当前的赋值，vscode左侧的调用堆栈，变量监视器等的都在实时跟踪应用运行状态
• 左侧的浏览器中是我们正在调试的程序，这是一个用node.js编写的计算器应用并处于调试终端状态
• 以上全部的操作都通过浏览器的方式运行，无需提前安装任何开发环境，SDK或者IDE。你所需要的只有代码库和SmartIDE。
• 以上环境可以运行在你本地电脑或者云端服务器，但开发者全部都可以通过localhost访问，无需在服务器上另外开启任何端口。

SmartIDE可以帮助你完成开发环境的一键搭建，你只需要学会一个命令 (smartide start) 就可以在自己所需要的环境中，使用自己喜欢的开发工具进行编码和开发调试了，不再需要安装任何工具，SDK，调试器，编译器，环境变量等繁琐的操作。如果我们把Vscode和JetBrain这些IDE称为传统IDE的话，这些传统IDE最大的问题是：他们虽然在 I (Integration) 和 D (Development) 上面都做的非常不错，但是都没有解决 E (Environment) 的问题。SmartIDE的重点就是要解决 E 的问题。

SmartIDE v0.1.2 发布说明

这是SmartIDE的第一个公开发行版，我们已经实现了如下功能：

• 本地模式 本地模式允许开发者使用一个简单命令smartide start，一键在本地启动基于docker容器的开发环境。全部的开发工具，SDK全部根据一个存放在代码库中的.ide.yaml文件通过docker容器镜像获取
• 远程主机模式 远程主机模式与本地开发模式提供一致的体验，开发者是需要使用 smartide vm start 命令就可以将开发环境在一台可以通过SSH访问的远程Linux主机上一键启动。
• 开发容器镜像 当前提供了 node.js, java, go 三类环境的开发容器镜像
• WebIDE支持 支持使用 vscode 和 Eclipse Theia 两种 WebIDE 进行编码开发和单步调试
• Web Terminal支持 通过内置于vscode/Elcipse Theia内部的terminal直接操作开发容器环境
• 传统IDE支持 支持使用 vscode 本地 IDE 通过 SSH 方式连接到开发容器进行开发
• 远程开发本地体验 通过 ssh tunnel 实现容器内端口的本地访问，允许开发者使用习惯的 http://localhost:port 方式访问开发容器所提供的各项能力，包括：WebIDE，传统IDE支持，Terminal支持等。
• 多语言 当前提供中文版和英文版两种语言版本，通过自动识别开发者操作系统环境自动切换显示语言
• 跨平台支持 当前smartide可以在 Windows 和 MacOS 两种操作系统上运行，并可以远程操作 Linux 主机，包括从 Windows远程操作 Linux 和 Mac 远程操作 Linux.
• 一键安装和升级：开发者可以从 安装手册 获取一键安装命令，并支持在现有版本上的一键升级。

欢迎大家通过以下资源体验SmartIDE的快捷开发调试功能，并通过 GitHub 给我们提供反馈

• 安装手册：提供Windows和Mac两种环境的一键安装和升级脚本，并提供2个更新通道。
  • 稳定版通道：提供经过完整测试的稳定版本，每2周更新
  • 每日构建版通道：包括最新的功能但可能会有不稳定的情况，每天更新
• 示例操作手册
  • Boathouse-Calcuator 是我们通过 IDCF Boathouse 开源共创项目 提供给社区的示例应用之一，我们已经在这个应用中适配了SmartIDE的配置文件(.ide.yaml)，您可以按照以上操作手册的内容体验SmartIDE的功能

祝各位开发者1024节快乐

SmartIDE选择了在这样一个特殊的日子跟大家说 Hello World。希望在后续的日子里面一直都有SmartIDE的陪伴，让每一名开发者的编码人生更加高效，快乐！

赋能每一名开发者，赋能每一家企业
– SmartIDE 团队愿景

2021.10.24 徐磊 @ 北京