 Okay, we are about to start and we can start our last speech. I would like to do a self-introduction. I am the developer engineer of UFAN Technology and also I'm a contributor of Jenkins. So I want to talk about the serverless Jenkins on Kubernetes. And actually Jenkins has a relatively long history and this program just was born from hustling in 2004. And according to the statistics of Jenkins official website around 250,000 Jenkins services operating now. And it has around 15 million other users and over 1,000 Jenkins plugins. Jenkins has made great success in the serverless but also there are some challenges. First of all, Jenkins has a relatively long history at that time. The distributed system is not popular so they may have a single point failures problems. So the users need to update or install the plugins from time to time so we need to restart it. And our CSD cannot operate normally and also Jenkins is a Java based program. Our CSD operation is usually run in the working time but we need to change the source code. So it may just consume a large disk space and increase our cost. Also Jenkins at that time of Jenkins, the physical resources scares and the users is unlike of us. If you want to start a CSD operation, we just create a hotspot for it independently. But at that time, Jenkins, if you want to possibly utilize a physical node. So it has an algorithm to try their best to use the node repeatedly and which leads to the slow operation of Jenkins. And also other CSD operation might influence the source. And also Jenkins, the storage of Jenkins can be sequenced into the hardest and might just consume the disk space and we need to deal with it by ourselves. Also Jenkins has many other problems. So Jenkins X just come to the market during this background. It was born from the JEP actually it is kind of enhancement proposals of Jenkins. So which was originated from Jenkins and currently the Jenkins X has already become a totally independent program. And the design concept of Jenkins X is to use the power of Kubernetes to construct and to build a modernized CSD platform. As for the modernization, I have two understanding of it. First is that it has modern architecture, for example, to solve the problems of the great consumption of the disk space. And also as for the enhancement of this experience, we need to provide automated a CSD for anyone who have done the CSD, we need to do a lot of work. For example, in KVX, we need to learn about the Docker file and to use the Docker build and Docker is not enough. Also we need to write some of the YAML and also we need the help to package. So these series of works are really painful and also I need to manage the environment. As for Jenkins X, so the users can avoid using these learning these new things and also Jenkins X can support the traditional workload as well as the cloud native workload. So in the initial phase of the design of Jenkins, it is different with the traditional Jenkins. We will think about how to create a pipeline and how can run it and to satisfy the demand of the customers. But from the initial design of Jenkins X, they need to think about what people want and how can we just design it better to cater to the perspective of the customers. So we want to have a faster time and to higher frequency of the deployment. So through the automated software delivery, so our build software and release of software can be more reliable. So Jenkins X during the initial design has done many of the research. This is a accelerator book has mentioned the high performance team, some of the methods that they would use. So Jenkins X has learned these methods and put them into the design of the products. So we need to visualize all the artifacts and to automate it deploy and also to have the development based on the main body. If you are interested, you can have a look of these books and you can learn many new things about the DevOps. So we have this graph of Jenkins. This is the original graph of the design Jenkins. First of all, this is from the perspective application. And in the traditional Jenkins, we all know that we are defining a freestyle job. And then we have a line in Jenkins X. We are defining an application and has a line. So when we are creating the application, also it has a provide a functional environment management. We can see it from the left graph on the both sides. We have a git repositories. There are three repositories. One is the application repository and one is the kind of the productive namespace. Jenkins X also take the environment management as one part of it. And all the applications in the environment are get up through the rectification of the code and through the OPS to simultaneous put into our environment. And Jenkins X also can have the function of the preview of the environment. So when we submit a pro request, it will just produce a service address after the codification. And we can easily see the environment directly, which is more easy to be observed. And as for the working process of Jenkins X, we can briefly scan about first of all the developer will submit a pro request to our code repository. And it will have a preview environment and relevant staff can review on it. And after the review, we will just put it into master. We only have one sub branch that is based on the development of the main body. We can have a faster release of it. And when the PR is in the master and you don't have a release version, this is only a small change. And this release version will simultaneously put in the stadium and Jenkins X will just execute the automated execution. And when the users need to go to the production, and we can put it into the production repository. And when this master is put into the master branch, it can be put into the production environment simultaneously. And Jenkins X during its evolution process also, it has inspired a lot of changes in technology. First of all, Jenkins X was born in GP and it was using the static Jenkins server like most of us. And then we have mentioned that the static Jenkins server has some problems like the single point problem. The assumption of the big specs and then they have introduced a pro as a receiver of the web hook, which is a high performance and a high available architecture. So static Jenkins server might always lose some of the information. So once we have pro, we don't need to worry about these issues. And even though we haven't introduced a pro, the web hook will not be massive or not be released. So we have another, that is the one shop Jenkins, actually like a Docker image. At that time, we use Kennedy View to run the Docker image and then to add it into Jenkins and to finally destroy it. And then in this procedure, we find that we're still using the JVM. Even though we are not running it for a long time, still using the JVM and also our loading time might be quite slow. And there are some of the performance problems. And then we have introduced Tecton, which is a very pure cloud native and Tecton. And in 2019, Jenkins X also has introduced on standardized definition used a YAML file. And next, I would like to introduce the technology behind the Jenkins X. First, I think the first problem we need to solve is the application package. Because Jenkins is from the perspective of application. So at that time, Jenkins has found a project called draft, which is also a cloud native project. So actually its concept is to isolate the user's contact. And when we choose a language, it will produce a Docker file automatically. And Jenkins X will utilize this kind of dot. And we have the buildX and there will be more files produced in the buildX. And even like the stock file, HelmChart, Scaffold, YAML and the series of the files. And they will automatically create repositories for them. Therefore, the users only need to finish the CSD. Most of the users don't need to just change this configuration. If they have higher demand, they will just have some changes of it. And once we have the lines, how to have some improvement in the architecture. So serverless Jenkins was born in this background. It mainly have the following characters. First, it just runs the lines based on the container. And also serverless is run based on the events. So our web group message. And also it is a loosely coupled architecture and highly available architecture. And also for our web hook event and for our underlying pipeline engine, which is a tecton actually, which was born in a candidate published by Google, which is a serverless platform. And in serverless, one indispensable part is that we need to build a serverless container. And the candidate have the build program. But once they have this program, the user wants to do more things. For example, one, whether we can have the unit test and we can have the code quality test. So we have a connected pipeline and currently this project is splitted up as a top project. And in many targeted, the cloud native underlying pipeline engine and Jenkins X is running on this tecton. Tecton has many good performances and characters. But most importantly, it can just eliminate the GVM. It has a faster running. And it uses CRD plus controller. It's APR is a declarative. We can just use it very easily. We can just work it very easily. And our CSD task will not fail due to some of the reasons. And after tecton, we may have to pro this project. Actually, it was born on the basis of the K8S. It has many of the repositories. Every day, it will have tens of thousands of the CSD guitars running on the serverless platform. So many of them messages came to K8S through pro and through other module of the CSD to be consumed. And also pro can just support a chat box. And we can have some comments to achieve, for example, how do we allocate the task and how to shut down this kind of task. So pro is just such kind of high-performance and high-available event reactor. So once we have this, we need to combine them. So CRD is actually a CRD controller. It's kind of like glue. Yesterday's conference, the speaker also mentioned that a CRD plus controller has become kind of like a hero of our story. So it means that we can have this kind of like loose cut point. And this will make sure that we have a quick start. And we have very rich, we have a lot of like community resources. And if we want to develop a system ourselves, we need to have a high availability of ourselves. So by using this kind of like combination of CRD and controller, we have much more convenience. And we also have these, this kind of real environment. And we have a good provider. And the pro and the QBIN8 is QBIN7 and the JX controller. The controller will create a solution and your job. And when we create the object and the QBIN8 is API server, we'll send the project creator event to JX controller. And the JX controller will receive the data and create a pipeline. In this way, you can see that this way you can see that all the orders, they are connected and you can just sort them in a little while. And the coupling is quite loose among all the components. So this is Jenkins X a more detailed structure. And actually we have a lot of components in this type of environment. And most important is that we have the pipeline operator in the Jenkins X. And Jenkins X, we have a lot of tech time. We have tech time pipeline and tech time task. It's kind of like definition of our flow of a pipeline and it will trigger pipeline run. And during pipeline run, we will also push temporary PR in the part to send the parts to edge. And if this NID task is successful and we will actually deploy it to the environment. So in this diagram, you can see the summarized structure. This basically actually has been confirmed. The one issue is that as I mentioned earlier in Jenkins, we do have like hardware. The storage in the hard drive may run out. And we encounter some issues in terms of the part and the definition. They actually, they're useless. And all those will be, all those data will be actually stored in the warehouse for the Kubernetes API and Jenkins X actually has defined using X core resources to clean the useless data. So we can actually use those to clean some of the useless data in the previous environment. Cleaning up the poach and cleaning up expired data. So JX and we have had to provide this GC and it will regularly clean those expired data. And also that when we develop the things on Kubernetes, they are actually indeed some problems in terms of the dev part. We will automatically need to sync local code to part and also it is difficult for us to, so we have this new dev code. So dev code can be kind of like a development environment for us. The dev code actually has two main functions. It will automatically sync local code to remote code. And if you write the code in IDE and you just use Kubernetes and it will automatically sync to the remote code. So you don't need to manually upload the data and for the deployment. It's quite quick. And also the another thing is that the S code you, I think you are all familiar with it. So it's kind of like web based. So you can deploy directly on the web page. And Jenkins tb poach, it actually has integrated these functions so you can directly add a deal code on the website. And this is a demo video. You can see that if you enter the dev code and it will return an address, you can open it. So we can see this familiar VS code page and then edit the code and open the terminal and enter the command to start the server. So we don't need to go through the complex procedure that we need to have. So we can directly visit it on using the web browser. So this one is actually a dinklex structure. So it actually includes a lot of modules. So for dinklex, it actually has formal functions than what is shown here. And dinklex actually has utilized the advantages of cloud manufacturers or providers. So for instance, when we claim the pod, what if we want to save all the data? dinklex actually has this kind of function. They will automatically sync those data to the cloud providers. And for instance, object storage or other storage. So in that way, we will have these kind of like... So now let's have a look at the demo. Here we have a pre-installed dinklex environment. And it's saved in QQE. So I'll just put it on into engine.cataball to have a look. So we can create, yes, create. And we quickly start and enter the name of the warehouse. And click confirm. And it will ask me to select the type of language. So for instance, if it's android or .net, so let's go for golam. And it will also initialize the warehouse and enter the information. And then it will start this warehouse establishment locally. So now it's completed. The procedure is completed. And if you actually use this command, you see the pipeline. So it's actually quick. And it has run some of the steps in here. And let me open the get up page. So here is the holocuba campaign that we just created. And it will automatically be sent to get up. And we can change some of the code here. Or I'll just... Because the time is limited, I'll just do a pre-lucast. So open a new project. And change some of the codes here. Okay, now we send it to the code warehouse. And do a new pre-lucast. We can click create here. So there's a webhook message. It has been sent and has been responded. And the user is waiting to be started. So actually I'm using... I used my account to kind of create this kind of robot. So the robot has certain messages back to me. So for instance, if I can assign the task to myself. And then the robot will help me to do all the things. And then I can do something just random. So you can see that I'm just doing some random stuff. And the preview will give me an address. And then we can open the address. And the changes that we've just made. And also the environment that we can get the application here. And we can see the project that we just created. And also the URL. So that's the end of our demo. So in the end. So this is the QKE Coversiphiers QR code. We are an open source container platform. And there's a Jenkins-China WeChat official account. I'm also a member of Jenkins-China. If you are interested in joining our community, you can scan the QR code and join us. For further discussion, do you have any questions? So I want to ask, where do you run the servers? Actually, just now when we are running the pipeline, we don't have a static server. Don't want to open my terminal. I can see some of the parts that I've run. And these parts are completely destroyed. In this process, we don't have a static server. We have one pro as a static server. And for creating a pro job and the same thing, you don't have a static running. And every time, it creates a new product. And just now, I think it's due based on the GitHub. If we do it. We can also have a similar result on other systems. So for our community, we are doing some of the develops based on these functions. Maybe currently, the GitHub has the best performance in the GitHub lab. The official website has a roadmap. And it supports from different github providers. I want to ask, as for Jenkins, it also has another function that has many plugins. And as for Jenkins X, as for the serverless. And these plugins also being used. So Jenkins 2.1 is called the next version of the CSCD. And another is called traditional Jenkins. And it will run some of the Jenkins server. You can use the plugins and you can gradually put it into the next generation of the CSC platform. And since our friends mentioned whether it can cover the GitHub, it don't have our full coverage. So many users will not use it directly. You can experience it first of all. Actually these plugins are not supported. Yes, maybe these plugins will not be used later on. So let's write the plugins by the side of this kind of files. It has other extension mechanism that is different from previously. You have add-on or private views, these two. And if I do some of the low end brain deployments, that is so different with the traditional Jenkins. For as for demo, we have said that we don't need to code it by, actually this code it by process. We have automatic way of producing the files and all these files we have included these things that we need to code it by. For example, in our demo file, but for some of the users, especially the developers, they don't want to learn this. We like to code it by our own chart, the definition of anything. And if we have few types, people can define few types for themselves and developers don't need to write these demo files. Still, they need to have a person, something that could be. But our code is more inclined to the features that we call. Because we don't like our service. We just change some code in it. You don't need to check a lot of things. Yes. Ultimately for the users, we need to do it from the perspective of the application. Current users do need to care about it. The double bound account chart is the cost of creating it as it was quite, it's not relatively new. And it doesn't have enough top layer architecture. So we won't choose, we don't need to write or run up the chart at all. The quality of it, which are to be likely in our developers. They don't need to care about what we need to change. We can just change the record. Thank you.