 Now I think most of us are here, so let's move on to our second speaker after lunch to introduce our second speaker we have. He loves football, he loves Manchester United, he loves FIFA and he loves WordPress. He's been a software developer for more than eight years and right now he's working at outside, not literally but outside as in company outside, a purpose driven design and tech studio based in Kathmandu. Today he will be speaking on WordPress development with CICD and to speak on the topic let me welcome Mr. Aayu Shrestha. Thank you Mr. Radha, I am Aayu Shrestha from Auschwitz Studio and my topic is how to connect WordPress to CICD. So my main topic is to cover today's topic, introduction to CICD, then how to connect WordPress to CICD and how to set up the deployment pipeline and then the continuous integration and deployment, why do we have to do it, I will focus on that today. So Martin Faulani has mentioned this, you can see this quote point, Martin Faulani has written a very clear quote, just what I have to say, the continuous integration is very important, removing it, it doesn't have to be a file, it has to be a case, the continuous integration is very important, finding it is very easy to find it, then it is very helpful to debug it. So let's, introduction to CICD. Before that, we need to understand how we are deploying it. We are directly connecting FTP, SFTP, we are deploying it. And what else do we have to do in our server? We have file manager, we can directly change the file and update it. And what else do we have to do in WordPress? In your backend dashboard, you have to change your file, obviously in config you don't have to restrict it, you can also update it and change it in production. So this is what we are deploying right now. So now let's talk about YAML, how do you know YAML, what is it? So yeah, okay. YAML is the markup language, in which the CI-CD code is helpful for language, you can see it in the build up burn life process. And just like the YAML file, your CI-CD code has maximum services, services like GitHub, GitHub Action, Azure Pipeline, and GitLab's own CI-CD pipeline, and your Circle CI is also there. So before that, let me tell you, this is the structure of YAML, it's a language structure, you have to see the name on the top, you have to set up the name, and then you have to execute the branch, you have to execute the branch master, and then you have to do pull request, you have to create pull request in migration, and then you have to do other jobs, you have to define the jobs, you have to do multiple steps, you have to do automation, you have to define the processes, you have to set up the steps, you have to set up the node version, and then you have to do panthen, I have given an example of panthen server, you can connect with other servers, likewise, you can test PSI, PSPT inside, you can see the secrets, you can see the secrets, you can also test your accessibility, you can test PSPTS, you can test the code standard, you can test the lending, you can automatically do it, so that's it, if you want to do CI CD, you already have a service, you have to maintain a high-quality code, if you want to do maximum code, you have to maintain a high-quality code, it will help you. I have said this before, maximum protocol is automatic, as I have seen earlier, you can see the PSI test, so it is automatic. So, what is your ideal scenario? There is no manual process, so you have to do CI CD workflow, you have to do the final stage, you have to see the code, you have to run the CI process, you have to run the CD process, so, how do you connect with WordPress and CI CD? You have to have multiple processes in WordPress and CI CD, as I have said before, you have to do the secrets, why do you use the secrets? Sorry, why do you have to do the WordPress? You have to do the WordPress app, you have to do the same, you have to do the same in your own development, you have to do the CI CD run, so, you have to do the same, why not follow, you have to follow the theme, you can follow the path, even if you are using WordPress, you have to do the CI CD, you have to do the same in your own development, you have to follow the theme, so, how do you do the build process? You have to do the build process, you have to do the build process, the build process is different, the whole dependency is different, you have to do the build process, So, your build process will be compiled. What is compiled? Your SAS file is compiled in CSS, your ES6, ES7, your browser debility is compiled in JavaScript, and we will teach you how to compile it. And there is another process, your test process. There is a test process. Even in the WordPress community, your test process is completely explored. Your test process is explored, but we can also do maximum tests, like a unit test, and the coding standard of WordPress is also there, and the LinkedIn is also there. You can do it. So, there is another process, your deploy. In the deploy, you have to do the secrets. The secrets are there. We have to do the tests before the deploy. Just like in the deploy, the secrets are there. You have to connect with any server. The secrets are there. We have our own secret. We have our own secret in the GitLab. So, we have our own secrets. We have a connection to the secrets. We have to do the connection. So, we have to keep the secrets there. We can keep the secrets directly in the YAML file. But the public of the YAML file is there. If it is public, then we know who is our personal secret. So, we have to go there. Because we have to keep the secrets there. There is an XOT entry in it. Even we don't have to keep the secrets. So, in the deploy, we have three types of deploy. The first deploy is there. There is a login and a theme in your WordPress site. It's not deployed. The login or theme, it's displayed in the WordPress site. The other thing is that, there is a login and theme in WordPress.org. We do not call it a generic theme. We do it as the login. We can deploy it in the WordPress.org. There is also a full-virtuesite. It's called a full-virtuesite. It is maintained by us. It's not maintained by us. It's all done and the full-virtuesite is deployed on it. So, there are three types of deploy. Other than that, this deploy is highly dependent on hosting platforms. Why? Hosting platforms are restricted. For example, if you want to sell a C-Panel, then you have to give maximum. In that, you have to give SFTV connection. We have kept SFTV connection in Githa Action Secrets. That way, you have to get a connection. Other than that, if you give maximum, then you have to give AirSync. AirSync has a small process. Other than that, if you want to sell an hosting platform, then you have to give a Panthen or a WP engine. That way, you have to give it a specific day. So, if you want to sell a Panthen or an hosting platform, then you have to give a family or a family. If you want to sell a Panthen, then you have to build it. If you want to build it, then you have to build it in Githa. After that, you have to commit. You have to do everything. You have to build all the assets. So, other than that, there is another process called Quality Assurance. Quality Assurance is not there anymore. We have to maintain the code. We have to maintain the quality assurance taste. We can do it automatically. Likewise, we have to have a selenium taste too. I have given you an argument. You can increase the PSI. You can increase the page auditors. You can increase all the tests. You have to have accessibility. You have to have accessibility. So, we have to increase the PAA package. I have given you an example. I have given you an example. You have to do a job. You have to run a job. I have given you three URLs. You have to test them. You have to pass through three URLs. So, you have to do this automatically. I have given you a PSB test. You can test it on your mobile. You have to have a threshold. You have to pass through the threshold. You can do it. I have given you a 70 threshold. You have to pass through the threshold. You have to pass through the threshold. So, how does the typical CICD workflow of your area work? Build, Taste, Deploy, We have to build, Taste, When the pull request is deployed, We have to deploy in the stage. And then, We have to do the production. We have to do the main topics. Like, Why do we have to do continuous integration? Now, Before CICD and After CICD. Before CICD, we have pros and cons. I have said it in the past, You can do the file changes, FTP planning, file management, Back-end pattern. You can quickly do the file changes. What are the things you have to do? Like, You can do it with colleagues. But the update button depends on what you want to do. And the push button depends on what you want to do. As soon as you do it, The person in front of you will be overriding. So, overriding, Obviously, there is a bug. My function is overriding. Other's function is overriding. Obviously, there is a bug. If there is a bug, It will take time to debug. And it will take time to debug. It will take time to debug. There is a concept of CICD. There is a concept of CICD. After CICD, You can do the pros. There will be a code review process. Your code is not overriding. My code is not overriding. As soon as you do it, There will be maximum processes. All automatic tests. You can do multiple automatic tests. After all the processes are automatic, After all the processes are automatic, After all the processes are automatic, After all the processes are automatic, After all the processes are automatic, It takes time to debug. Some people might say me. I cannot even reboot. I was stable when I was in the first stage. This is stable. Why not to reboot it? There is no downtime. So, what is this? I will face your only feature. It is your initial setup. If you see the normal file, you can see the secret layer of GitAction. And the connection of your server base, the accessibility test, or the Lintin test, or any other testing. We have to manage these three, because we need a little more time. Now, that's how it should be. Why use it? How it should be. Smaller code. Smaller code can also be changed, and it can depend on others. And faster release. I will make one module, I will make one module, and it can be reviewed by others. I have gone to that production, and it can also depend on others. And the maximum processor, your workflow is automatic, then I know that there is an issue in the workflow. You can debug it. Time save. Obviously, time save, cost save. And then there is fault isolation. I have told you, you have to come to any issue. You have to come at any time. And you have to see that workflow. For example, if you have a case speed of 70, it will be 60 or more. I have to add this module, and it will speed up. Obviously, there is some fault in this module. So, we have to optimize it. We have to make it as it is. Now, another point, security. As you can see, we have to develop FTP, back-end code, dashboard, file change, how many of us have developed it? How many of you have developed it? If we are working, how many of you have developed it? If we are developing it, if we are developing it, whether it is a company or something, it will still access it. So, it will still access it. We have to change it time to time. So, in CICD, it is not so hard to block the user by giving access to user. So, that is all. That is all. Thank you. What is the question? What is the question? Anyway, what is the question? That is all. Feel free to raise me. Thank you.