腾讯云 Serverless Framework 正式发布会

  • 1
    关注“腾讯产业互联网学堂”公众号加群互动有好礼相送
  • 2
    回复【加群】
  • 3
    添加小助手微信号回复关键词【SF】
  • 4
    加入交流群
腾讯产业互联网学堂微信公众号
“腾讯产业互联网学堂”微信公众号

简介

腾讯云 Serverless Framework 正式发布会,主要分享Serverless:云计算的下一个浪潮,Serverless Framework 未来展望,Component Registry,云端的Serverless Component生态以及Serverless最佳实践等。

讲义

Yunong Xiao:

1、Serverless:云计算的下一个浪潮

我们认为它是云的一个未来,给客户、开发者最重要的价值是,专注于业务,而非底层资源。它有三个比较重要的点:Services auto scale only when you need them(自动伸缩扩容)、Only charge you when they run(没有用Serverless产品,不会生产费用)、Lowering the barrier of entry(降低门槛,更多的开发者可以使用云上的服务)

2、Serverless Framework

Serverless Framework产品是一个全球最流行的品牌、口碑最好、技术最好的Serverless应用框架。

35000+Github Stars,全球top50

40000+装机量

1000000+月活Serverless应用

2019年1200万下载,增长率240%

3、Serverless Framework正式版

正式版是一站开发Serverless Full Stack应用的解决方案。

一键部署:国内仓库、云端部署引擎、极速部署,让你在云端可以去很快部署全部的业务。

开发调试:实时日志、云端调试

组件市场:注册中心、丰富易用。让开发者可以选择找到很多非常通用的组件,不用自己从0到1再去建设。

Serverless三步上云:开发者扶持计划

Serverless Framework正式版为开发者提供限时30天免费试用。

4、Serverless,未来已来

我们的目标、定位是做全球最优秀的Serverless平台,我们认为 Serverless是云的未来,我们跟Serverless.com这家公司建设的这套Serverless的开发平台,也是云的未来开发平台。

Austen Collins:

Serverless Architectures. The architecture with the lowest total cost of ownership.

Generally first of the biggest value proposition of that we see often is just that it's as the lowest total cost of ownership,the lowest total cost. And this is what brings most people to the Serverless architecture。If you have software that has ownership maintenance requirements,scaling requirements,cost management requirements,and you're looking to deliver a software,that is a lot more simple to manage. There's no better option than the Serverless architecture。Here's what a typical Serverless architecture looks like. This is what we call a surplus rest API , this is probably one of the most common use cases Maybe the second most common use case of the Serverless architecture. The first most common use case is stream or batch data processing jobs. Some people call it the Serverless Architecture. Some people call it the service full architecture。Because, the architecture itself is comprised of multiple cloud services. We're using the Tencent API gateway to receive http requests in this rest API. Tencent service cloud functions to process the business logic, reaching out to either Tencent Cloud Storage or Tencent Cloud DB for some persistence. This is what the Serverless architecture looks like most often API gateway product is auto scaling. Surplus cloud functions is auto scaling.

Now Tencent finally has postcards which is an auto scaling daily cases。It really completes the storage for the Serverless Architecture. So key characteristics of this,why people like this is this comprised of these auto scaling services. Most of these you don't have to pay when these Serverless are not running. This typically requires about twice as less about only 50%of the engineering team. And you focus on outcomes down infrastructure. This scale can serve millions of users. These are the top Use-Cases, We most often see with Serverless architectures against dream batch data processing jobs. These are image manipulations, file manipulations from a cloud object storage bucket. to rest API to graph API is very common now. As well as adventure and workflow,and even some edge compute is starting to be a popular use case。

Now,when Serverless architecture started to emerge,the application experience,the developer experience was pretty hard. At the end of the day,there are a lot of cloud services,which you have to know and understand how to use. And that's why we came out with the framework. And what we offer with the service framework is a great developer tool for zero friction application development. One of our big value propositions is the developers can build rest API's data processing,pipeline lines,schedule tasks,without having to be a master or an expert of the cloud infrastructure. So we've got started in 2015,and since then we've been growing pretty rapidly. Github Stars 34,900. But most importantly,I think everybody is who's doing service has kind of adopted the service framework as a standard,because it's open source. And it's very easy as a big community behind it and It's very easy to extend. Some of our big customers are JPMorgan,the bank NORDSTROM,LEGO, Coca Cola ,Nike, Some examples,some case studies for what these customers do with the framework. Coca cola does all of the north American marketing projects with the surplus framework. Nordstrom does almost everything from rest API’s to data processing pipelines. When you go on Nordstrom.com, the retail site Every time a user clicks anything,click stream activity is being sent up to a single surveillance function. And that service function is processing the billions of quick stream events. And using that to personalize the user's experience on Nordstrom.com. So as they click that data,what they are doing goes up to a single cloud function and changes the content on the page.

So they can have an experience that's more relevant to them as they shop. Nordstrom also the again they have about four thousand five thousand functions now. Doing everything from data processing pipelines to the click stream activity to rest API is power and customer facing experiences. Our school sports is a recent new user of ours or they've been service for a couple of years. But what is most exciting about them as they were a startup?That went mostly surplus. They have the small teams ball engineering team. They decided to do most of the Serverless architecture. And they recently sold to a much larger company for about $500 million. I think Serverless help them. Do a lot more with less resources leading to a great outcome at the end of the day.

About a few months ago,we announced our partnership with Tencent cloud. This was very exciting for us,the Serverless, our company,because this is the first time we had the opportunity to pair with a cloud provider,who was very interested in being the premier service infrastructure provider in the world. So Tencent came to us and said that they wanted to build the world's best service cloud infrastructure. They want to give developers everything they needed all types of infrastructure that's auto scaling. They never have to pay for idol. And that was very exciting to us. And also I wanted to partner closely with us,and offer us the opportunity to really control the developer experience on top of the next generation surplus cloud infrastructure that they be building. This was an extraordinary type of partnership. We jumped at the opportunity to park with them. And our goal with this is we want to offer a service cloud experience,rethinking the cloud from a surplus perspective. We want to offer the best service cloud infrastructure. Things from service cloud functions to API gateway products all the way to Tencent new a service post grass. So the best cloud service cloud infrastructure combined with the best possible developer experience that working very closely working quickly and since we announced our partnership in November of 2019,today we are excited to announce that Tencent Serverless Framework is now generally available. This is a custom slick experience for developers,especially in china,this is an experience just for them. And this represents probably some of our most progressive ideas,some of our most advanced ideas for how you build and maintain applications.

So our gold with this project,we're really about 3 specific goals.

That was first stuff we want to make sure that developers and even companies who don't have a lot of cloud experience are able to deploy applications on the civil cloud services,cloud infrastructure without a lot of knowledge of the infrastructure. At the end of the day,you don't have to be an expert to do this. What we're trying to do here is we're going to give you an experience that allows you just to focus on your application,using an experience,an application framework that you might already know. And we will auto deploy that on the service cloud infrastructure. Without and glue the infrastructure pieces together set the right configuration defaults,put together all the best practices and patterns on the cloud infrastructure. So you can focus on your app. We control that great deployment experience. So number one allowed developers to focus on applications,not infrastructure.

Number two, We think that for developers,one of the most important features is speed. We think speed is the killer feature,and that is enabling developers to work as fast as possible without distraction. Without getting slow down,especially by deployments,pushing their changes to the cloud. So if you're serious about cloud software development and especially Serverless development,those services only exist on the cloud. We want to make sure that developers can push their changes to the cloud as fast as possible without having to sit around and wait.

Lastly,a rapid development in addition to fast deployments. We wanted to make sure that developers could get feedback from their changes as fast as possible via Logs, a debugger that runs live. That allows you to step through your cloud a code on the live cloud infrastructure. So let's take it from the top here and dig into each one of these.

Applications not infrastructure. So what we've learned working with a service developers for a long time,is a lot of great cloud infrastructure out there. A lot of developers really like focusing on their application framework that they know. So some examples of this are expressed JS the popular application framework for building back in API is a particular or cola. Another popular back in framework on top of JavaScript,as well as php framework. The one part developers love this application framework. In addition to friend and developers they like building with react. So we wanted to give them an experience where they could just take their existing express applications their existing reactor view applications,and actually deploy them instantly to service cloud infrastructure. Without really having a re-architecture applications or relearn,or learn about all this new climate structure. So what we are going be giving you today is something called Serverless framework a components,and it's focused on specific outcomes. So you could deploy express,you could deploy a lot more on the service cloud infrastructure without being an expert of in that infrastructure. So we have a handful of these that we've been working on for a while. We'll continue to launch these until we give every developer. It is an experience that for they're familiar with,so they could deploy on the infrastructure without having to be an expert.

Next Fast Deployment. This is a big one for us. This is something we have been working on for a long time. Traditionally,when you're pushing changes to the cloud,it can take 60 seconds,a full minute or much longer. So what we've been focused on is just reducing that time to around five seconds right now. That is our average. We still have a little ways to go there. But in general,this is the fastest deployment experience. That's available today when it comes to on the cloud. So we are trying to make that deployment experience as fast as possible. But now as a developer, You could easily spin up your development,environment to your testing environment,and staging environments,even just a whole other environment for a specific feature. And you can deploy quickly write your code change and deploy quickly to see your change on the live cloud services. And the most important part is these cloud services. That the developers are working on are the same cloud services that gratification will run on in production. So there's be no surprises,no differences. When you push those changes over to production,and you won't have to compromise on speed. So you push it,you write your code,and you push the deployment to the cloud really quickly. Some of our inspiration here is to try and copy what the front and community is doing with hot bonds and reloading. We hope to get to a point where your changes are pushed to the cloud uh instantly. We made a lot of progress. And we will be all of this shortly.

Lastly is rapid development, so giving developers experience that they're familiar with,so they can work with express,and then allowing them to deploy that to the clouds and deploy changes. It's fast as possible. And where our first two goals and they all kind of play into this. And that is a great development experience. That's really fast. And lastly,the last part of that is feedback how you get errors,how you get feedback from the changes that you push to the cloud. So with this new announcement,we have a whole new surplus death mode. And if you run service death with the framework,we're doing a few things. So watching your code and auto deploy every time you hit safe. So as you work in your text editor and you make that code change and you hit save,we're going to use our fast deployment technology to push the change to the cloud.

Instantly, while death mode is open as you interact with your application,whether it's a certain a single service cloud function or a whole express JS application,when you interact with that,all of the coming from them,application running on the live cloud services are going to stream to see a lie in real time. It is instant,it is fast. And you will get,you'll see every single console statement that you do as well as errors. Be streamed in real time to your CLI so you can see feedback on your changes immediately.

Third,we're also offering a debugger that allows you to step through your code on the live cloud services. And when you run surplus death,you're going to get a u l that allows you to open up that debugger and actually see what's going on in your service cloud functions. So that you could inspect the environment and debug more quickly. All of this is available today. Again,just going over our goals. One last time allow you to focus on applications. Not infrastructure,I used to deploy as fast as possible to the cloud and then allow you to iterate and have rapid development be a real time streaming logs. Streaming errors,code watching and live debugging on the cloud.

黄科:

一、Serverless Framework 未来展望

1、Serverless Framework的演进,从V1到Component、

从V1版到现在的component版本,主要有两个大的版本,一个是Serverless Framework V1,一个叫Serverless Component,就是我们今天的框架。

为Serverless框架的发展奠定了基础

Serverless Framework V1从4年多前就已经发布,到今天为止已经积累了非常多的用户。我们通过这4年多的经验,也看到了大量的基于Serverless Framework应用的场景,也学习到了开发者是怎样使用这个框架,以及怎样使用这些底层的基于Serverless云资源的。

V1版本最大的带给开发者的不同就是,对不同的云资源的底层架构进行了抽象,也就是说你可以通过V1去使用AWS、谷歌的一些云函数等,所以使用Serverless Framework就有能力去使用各种云资源,通过一个简单的配置文件,配置底层的云资源,需要什么参数来保证你的应用程序能够运行在云资源上。

它的配置非常灵活,可以提供非常细节的各个云资源的一些配置参数。同时 Serverless Framework V1也有一个第三方插件的体系,所以第三方开发者也可以开发其他云的支持的插件,有点像早期的Component,所以从插件系统我们就看到了,有这样的一些插件,它其实又对云资源进行了抽象,做了一些针对应用程序开发的封装,从很早这些用户使用Serverless Framework的过程中,我们已经看到了这样的一个趋势,V1版本推出以后是很受欢迎,但是经过这几年的发展,我们也慢慢看到了它的一些局限性,比如它的配置还是非常复杂,因为在配置当中,其实你还是需要特别关注底层的云资源到底是什么样子?比如说作为一个应用开发者,必须去学习什么叫做云函数?如果以前没有听说过云函数这样的概念的话,必须要去了解什么叫做云函数,会发现基本上所有的云厂商的云函数里面都有一些概念,如处理器、配置处理器的代码?怎样配置云函数的触发器,通过什么事件触发?所有的这些概念,如果我是一个经常开发express APP的应用开发者,对我来说这些概念是全新的,需要花时间去学习,因为我只了解我的应用开发的那一部分,所以有新的东西需要去学习。

需要通过Serverless Framework部署的应用,需要依赖部分的Serverless的框架的一些类库。比如我是 express API组件的开发者,我除了依赖express框架外,还需要依赖一些Serverless发布的框架,而且有一定的学习和研究成本,必须知道我用哪一个,应该怎么样把依赖引进来,所有的这些工作其实是和我开发express API这件事情不相关的,但是因为我要部署这个东西到Serverless的架构上,必须要学习和了解这个东西。所以就是说应用的开发者,还是非常需要关注底层的架构的细节。

基于4年多来框架使用案例的思考及总结

经过了这么多年的发展,插件系统、第三方的插件以及使用 Serverless Framework的一些经验,让我们有了今天的Serverless component V2版本的框架。这个框架主要就是让应用开发者回到对应用本身的关注上,所以如果你是一个express API的作者,或者只是想部署一个静态的网站,你只需要去关注自己所需要关注的应用开发的部分,而不用去思考,说我如果要把 express API部署成全部Serverless的架构,到底应该用什么东西,不用学习怎样配置云函数,或者怎样创建 API网关,甚至什么是AP I网关可能都还没有了解过,你现在不需要太多了解这些细节,而只关注现在的应用,所有的这些东西是应用开发者自己本来就关心的东西,没有任何新的一些概念在里面,全都是已知的概念。所以配置被大大的简化,然后让大家更聚焦在应用的实现细节上面,而不是架构上面。

开放Serverless Component生态,希望提供非常多的覆盖各个语言、框架、应用场景的一些Component。腾讯云官方会有大量的一些Components覆盖,有相应的Components来帮你快速部署对应的语言和平台的应用到Serverless的架构之上。所以整个部署Serverless APP的过程变得非常的简单,同时该框架的另外一个目标就是说,在部署变得简单的同时,也不牺牲线上运维的一些能力,比如说线上的纠错、调试APP、查看日志、查看应用使用的数据,并且这些东西现在变得更简单了,之前你作为一个APP的作者,为了获得线上,比如查日志的能力,除了开发应用本身之外,你还需要花大量的时间支持这些运维的东西,但是现在通过Serverless Component,以及腾讯云的基础设施后,会发现你做应用的开发之后,就自然获得了这些能力,所有的这些东西都是开箱即用的,而且当你开发完成后,它就已经是为上线准备好的一个东西了,不需要你再去做过多的运维的工作,开发一些其实你应用程序逻辑之外的东西。

二、Component Registry,云端的Serverless Component生态

Serverless Component生态

我们的目标是建立丰富的Component生态,希望覆盖各个领域的应用开发者,无论他们使用何种语言或者平台,都可以拥有刚才我说的快速部署、不需要关心底层的云架构,同样获得产品环境的能力,所以我们慢慢丰富生态的同时,其实Component生态也是允许第三方,比如有些开发者特别擅长于使用腾讯云的底层的资源,拥有非常多的知识,他可以去开发自己的Component,甚至可以把自己的Component提供给其他的应用开发者用,其他的应用开发者也就可以获得这种能力,不需要像这位开发者一样,这么精通这些腾讯云上面资源的使用,但没有关系,他有了这个Component以后,就可以复用这样的逻辑,可以非常快速的部署应用。

我们希望生态是开放的,为Component开发者提供了这样的流程和框架,让component开发者也可以为生态贡献。

开发:基于Component开发框架编写代码,封装对云资源的操作。

描述:描述Component针对的应用开发场景、版本、作者信息、文档位置等。

测试及发布:发布测试版本进行测试,并提交正式版本到云端的Component生态市场中。

应用开发者选取Component部署serverless应用,应用开发者从组件市场中选取组件,基于对应组件发布自己的Serverless应用。

三、云部署引擎+云端调试体验,将DevOps完全迁移到云端

接下来给大家看一下这次的关键功能,背后的一个大体的架构和实训原理,比如我们所有的部署现在都是在云端完成,你本地仅仅只保留了代码编辑的环节,你在编辑的同时,所有的东西会被自动部署到云端的Serverless架构上,可以实现云端的调试。这背后我们是怎么样做的?这里面会解决一些关键的问题,如如何提升应用的部署的速度,因为如果你想让所有的开发所有的代码开发一旦开发完,或者保存文件后,它能够快速的部署到云端的资源上,那你的部署速度是非常关键的,能保证对本地的任何一个代码文件的修改,经过几秒钟后实时部署到了云端,所以你可以完全依赖于云端的资源进行开发。另外就是如何进行远端调试。

这一版本的Serverless Component,运行的背后有一个叫做云端部署引擎,它的作用其实实现就是为了实现支持刚才说的那些特性,如快速的部署、支持远端的调试等。整个过程,你还是在本地去开发你的应用代码,然后你会有一个部署的描述文件,描述文件不需要去配置,任何的就是和底层云资源相关的这些东西,你只需要配置你自己关心的,每次代码的修改以后,就会通过描述文件和你的代码,把这两份信息一起传递到云端的 Component执行引擎里,它会识别到你描述文件里所用的component是一个express component,会到我们 component的市场注册仓库中,找到该component,然后运行 component里面的一些逻辑,来帮你把这个代码部署成底层的云资源,最后部署完后,他会把部署的结果返回给你的前端,所有后面的Serverless的一些特性,比如自动伸缩、灵活计费等这些特性,你的APP自然也就有了。因为所有的这些APP,它最后还是运行在这些底层的Serverless云资源上,具有这样的一些特性。在云部署引擎的基础上,就可以实现远端调试,待会下一位讲师会分享。

四、Serverless Framework未来展望

目前的Serverless Framework已经具有了刚才讲到的特性。这个框架我们还在快速的迭代上,和腾讯云一起很快的往这个框架里加入更多的能力。

更完善的 Serverless组件库生态。支持各个语言、各个框架,基本上覆盖各个应用场景的 Serverless Component的组件库,可供应用开发者开箱即可用。

差量部署,极速部署体验。进一步优化部署的速度,现在可能是5秒6秒,那之后我们有机会把部署优化得更快,比如两秒三秒,我们会通过差量部署的方式,不用每一次都部署完整的应用代码,而是只部署你修改的应用代码,来实现这种更快速度的在线部署。虽然你的东西运行在云端,但基本上就和本地开发是一样的。当你开发完,其实它就是一个部署可以上线的东西。

包含线上运维工具的Serverless Dashboard。通过网页端的控制台,就可以管理所有已经部署的这些实例,同时也可以这里面云端的Dashboard也会提供各种各样的运维的工具。我们希望通过 Dashboard提供一套线上运维的工具。你在本地开发完成以后,就已经部署到云端,同时所有的这些运维工具就已经可用了。也就是你完成开发,在云端就已经可以收集到指标、相关的数据,所有的这一切都不再需要你去写,我们会以很快的速度不停的推出各种各样的产品,能让基于Serverless component开发应用,无论是开发的体验,还是运维的体验都越来越好。

方坤丁:

一、为什么你要用Serverless Component

相信每一位开发者在使用的时候都会遇到问题,如云上产品配置复杂,学习成本高;框架迁移往往需要改造,无法无缝部署到云端;本地开发,云端调试——本地/云端多次循环同步,效率低。这些问题其实不仅仅是我提到的这几个痛点,它是贯穿整个开发生命周期的,从开发、调试、部署、运维、安全性方面,整个生命周期都会遇到各种各样的问题。

这次发布的Serverless framework,包括我们一直以来,腾讯云和Serverless结合在做的一件事情,是让客户能够更多聚焦于自己的应用上,而不需要管理底层的云资源的具体详细配置。从结构上来看,对于用户来说,可能只是想要实现一个REST API,或者部署SSR的业务,或者做静态的网站、静态的个人博客,但是在真正实现的时候,和云的具体服务之间会有一些差异,Serverless framework一方面通过Serverless component的组件化的能力,提供了各种各样针对应用的一些组件。

还有Serverless framework Develop Debug Deploy Monitor,来做标准化的统一,让客户真正不需要理解这些具体的配置是什么,而是直接通过写自己需要了解到的配置,其他的只需要通过一些默认的设置,就可以帮助你来部署,快速实现自己的一个应用。Develop Debug Deploy Monitor同时也提供了一些监控、运维、云端的调试、开发过程中的优化这些能力,来赋能我们的开发者。

二、全新发布特性一览

主要分为三个部分:

一键部署:国内仓库、云端部署引擎、极速部署

首先Serverless framework是针对国内提供了国内的仓库,包括国内的注册中心,因为这样,它的访问速度包括使用体验会有一个很大的提升,另外在部署的体验上,我们也提供了本土化的交互的体验,然后客户在新手使用的时候只要输入Serverless就可以提供很多交互式的一个应用和指引。另外支持了云端的部署引擎和注册中心的能力,支持将每次部署的一些状态直接存储到云端,还有Component直接存储到云端,这样的话就保证了部署的时候的速度,可以实现本地和云端的极速同步。

开发调试:实时日志、云端调试

在开发调试的阶段我们支持了一个开发者模式,能够提供实时日志的输出,另外能够支持直接对云端的代码进行远程调试。

组件市场:注册中心、丰富易用

提供了一个支持各种各样框架、语言的注册中心和组件市场,丰富的组件生态一方面可以直接让开发者把它下载下来进行复用,或者如果有需要的话开发者也可以自己基于这个来进行改造,并且把它推到注册中心上,也可以把它分享给其他人,然后来贡献、使用,从而达到一个非常良好的生态。

我们会针对中国客户提供了一键部署的能力,在最新版本的SF里面在一个空的目录下面输入Serverless的时候,直接会有一个交互式的体验,会引导你去直接选择。一键部署的流程已经将预制的包直接下载到本地,并且部署到云端,这样就避免了其中很多各种各样的情况出现,能够让我们有一个更流畅顺畅的体验。针对我们的中国客户,底层的资源也是部署在我们国内的地域,这样本身的性能上会有得到保证,另外在云端的部署引擎上,是能够通过不同引擎中存储的部署状态和你的Component本身的信息,也就是说不需要先把我的Component下载到本地了,直接可以调用云端的Component就能够实现一个急速的部署,可以非常方便存储和共享自己的状态。

在Dashboard里面,可以看到我部署的所有的Serverless应用,可以看到就是我之前部署的应用的状态、部署的信息,还有最后一次的部署的时间等等,都可以列举出来。

在Dashboard上也可以直接通过点击按钮快速部署第一个Serverless应用。非常希望我们的第三方或者开发者来去贡献自己的组件,这样的话你自己也可以直接在这里面看到你发布完成的组件并且来做复用和共享,从而构建一个更加丰富的良好的生态

三、最佳实践

1、Serverless应用的组织和引用

在这次新版本发布之后有非常多的客户会问到怎样组织我Serverless应用,就是说我在Serverless应用之间,当我用到非常多的Component,怎么互相引用,他们之间是怎么关联的,我们也可以看到在一个应用的时候呃可以看到它会有三个不同的文件夹然后嗯这三个不同人家分别是静态的website端、express组件API、Serverless db组件。

组织方式:

将应用拆分为不同模块,通过目录区分。

部署/移除时支持根目录遍历。

仅改动某个模块时,通过—target制定具体的模块进行单独部署。

通过.env.stage的方式区分不同环境的变量。

引用方式:

相同 org 下的组件,通过output方式互相引用。

指导app和stage区分环境。

当组件之间互相依赖的时候该怎么引用,通过填写的字段来关联和组织应用

2、Serverless CI/CD

我们现在和CDOING的结合中,已经支持了多个方面的打通和结合。一个产品从一个想法的诞生到真正上线的全流程,coding在这里面的每个环节都有涉及,都有非常强的能力。比如在最开始的时候它的一个项目管理能力,有一个类似于迭代的管理,有一个看板的方式。在开发、持续集成和持续构建、测试的时候,也是支持了自动的构建、持续集成、持续部署的能力,并且也支持代码的托管。在这样一个流程里面我们的Serverless是怎么样实现这种CI/CD的最佳实践呢?我们做了几个结合点:

在我们的coding devops创建的时候,会提供一个预制的模板,支持了Serverless Framework的全栈full stack网站模板,同时也支持一些像静态建站的模板,对于我们的用户来说,只要把这个模板选取点击后,就能够跑通整个流程。因为预制的模板是默认把代码下到你的代码仓库里,并且帮你自动构建、自动部署,然后在这之间会去帮你装npmserli,然后会帮你做搜集plus这些操作,在这个流程跑通之后你直接可以在项目的看板上直接就看到你一个部署好的应用。那在流程跑通之后,其实我的CI/CD本身已经预制好了,那如果我希望进行进一步的开发或者对我的这个业务进行迭代的话,也可以直接点击clos studio,提供了work的能力,是默认内置了Serverless的安装框架的,也可以直接通过这个框架来方便进行一些自己的调试、部署。手动构建也是完全没有问题的,手动空间也可以打通CI/CD流程,能够帮你持续的构建、持续部署,并且如果需要写一些测试的话,那就直接在整个的CI/CD流水线里面自己增加一些脚本或者增加一些配置就可以了。

四、实战演示

欢迎观看视频,动手实战~

全部评论
讲师/助教

评论

直播日历