 Okay, we have a couple of students, right? Fine, so let me start the session. Okay, before that, let me do a self-introduction. So my name is Safanaj. I am coming all the way from Sri Lanka. And currently I'm working as a software engineer at Cisco Labs, a small advertisement here. And these are some other communities that I'm being a part of. So if you want to get connected with me or if you have any queries, you can reach out to any of my social handles. So yeah, that's all about me. And yeah, the agenda is simple. We're gonna talk about what is CID? Since this is going to be a beginner friendly and why we need to use CICDs and what is actually GitHub actions and what are the benefits of using GitHub actions? And finally, we can have a demo if the time allows. Okay, let me remind you the hashtags for today's event. So if you are posting something on social media or if you are sharing your feedbacks about my talk, make sure to follow these hashtags and my handles. Okay, let me tell you a story of a typical developer. So as a typical developers, we used to develop applications and then we do some manual testing locally in our PCs and then we deploy it, right? Then we used to pray to make the deployment successful and we will be, again, do some testing on the environment and if it didn't work, we had to go back to the develop stage. If it is work, we had to pray more to keep the application successful. So this is the saddest life cycle of a typical developer where CICD was never exist. And that's where DevOps came into picture and back in 2000s, like departments like developers and QVs, IT team and security, they worked individually to achieve something like machine in the IT industry, right? So basically developers used to code and QVs will be testing, you guys know the stuff, right? So CICD, can someone tell what is stand for CICD? This can more into specific into students. Yeah, it should be continuous deployment or continuous delivery, yeah, it's correct. Okay, I will give some GitHub stickers, make sure to ping me, okay. So CICD stand for continuous integration and continuous delivery or deployments. So let me start with what is continuous integration? So it is actually a phase and the practice in software development cycle. So where developers work together in a single project and regularly do merging codes. So this is basically, we will be taking out some basics such as a unit test and integration test. Maybe you can have some code quality checks. Within a short lived environment. So what does it mean by a short lived environment in the sense? So you just need to spin up an instance. You have a simple need, right? So you don't need to run all the time. And you can set up your repository where someone, every time they push the code, the CI can trigger and it will be running. So if there are any build or fails, it will notify the relevant team. So you can have a look at what happened on CI pipelines. So typically the CI pipeline involves the following task. So it is used to direct changes in resource code and we can build and generate the artifacts that we need to deploy. And also we can form basic tests such as a unit test and integration test. And you can have a status of report. So if you are having a code checker, so there will be a status of report of what is the percentage of your coverage. And if the above steps fail as earlier, this will notify the relevant team. So you can have a look and fix the stuff. So there are some ways of using CI. So first one is to develop a productivity. So you don't need to build applications manually where it's time consuming actually. And so there you can save some time and you can find the bugs and address it earlier before it's free to production and grow big ones later. And you can deliver a bit faster, right? So you just push the foot. So the CI will be running. So you don't need to spend some time on your menu works. And let's talk about what is CD. So CD is a suffocating approach. So what changes can automatically deploy into a configurable environment. So it could be a testing or production environment. So in practice, in simple term, developers code changes can go into live within a minutes after writing it. And if we can discuss about the benefits of using continuous delivery, it's automated the process of software releasing. So you don't need to build the stuffs and take into the server or whatever the platform that you prefer. And again, the developer productivity is high and you can find and address the bugs earlier and you can deliver the update fast. So typically CI CD pipe can contain cases. One is where you can get and test and generate some artifacts for your pipeline. And the second phase is CD. So where you grab the artifacts and deploy into a server or something. So let's talk about the get-up actions. So automated workflow from idea to production. So we have seen such as some eight phases in DevOps cycle, right? So you can automate all those eight phases using get-up action. So you don't need to spend some time on your manual works in any phase. So when it comes to achieving DevOps culture in your company or your business projects, so automation is a crucial component, right? So get-up actions allow us to automate, customize and execute your software development workflows right from your repository. And yeah, you can build, test, and deploy from your repository. So you don't need to spin up some server. You don't need to connect your repository with some webhooks. You just have the configuration. That means the workflow file in your repository, it's simple as that, it will work. So why we need to use get-up actions? So the first point, it supports multi-operating system starting with Linux, Windows and Mac and containers. So container is something we need to highlight here. So if you are coming from a Docker background, so you don't need to go with VM, so you can simply run your CHD stuff containers. And metrics means if you want to test your application in multiple operating systems, such as Linux and Windows, parallelly get-up actions allows you to do that. So you can save more on that. And any language, so far it supports most of the programming languages, such as Java, JavaScript, and you can see in the slide, go root and stuff. And live logs. So right after your workflow triggers, you can see the logs, what's happening in your CHD pipeline. So if something goes wrong, you can have a look at your logs and you can fix it earlier. And the next point is built-in secret store. As a good developer, it is a best practice not to hard-code the secrets and token stuff in your source code or pipeline. So get-up has its own secret store where you can have an organization-level secrets or a postal-level secrets. So it can be, you don't need to hard-code the stuff. And multi-container testing, again, it's similar to DevOps stuff. If you want to run a CI CD against your containers, so you can have a multi-containers and make it easier. And again, it's simple, right? So you don't need to be a super-duper expert on DevOps. So if you are a developer who knows some basic stuff on how to run a CI and how to generate artifacts, it's simple, that's it. You don't need to have a wide-end DevOps knowledge to do a good get-up and actions. And there are like five components in get-up actions, even steps, jobs, actions and runners. Let's discuss one by one. We all together we call it as a workflow file, which need to be written in YAML. So a workflow is simple. It's a configurable automated process that will run one or more jobs in your repository. So it's need to be defined in YAML yet another markup language. So a single repository can have multiple workflows. So you can have a workflow to run a CI. You can have another workflow to do some link testing. You can have one more workflow, any number of workflows in your repository to perform some different tasks. And it's need to be defined in the directory code dot hub slash workflows. Otherwise it won't work. And again, there are some rules for that. And a workflow should contain one or more events that can trigger the workflow. It's need to be triggered, right? It can have one or more jobs to execute the workflow in your animations. And either you can have a script or you can use actions templates. So typically this is how a workflow file will look. So this is a simple node CI pipeline. So here you can see the event will be listening to on push event on master branch and the program request for the same master branch. So when someone made a, someone actually directly pushed to the master row, some made a PR to master, the workflow will start. And here you can see we can have a variables defined there. So you can reuse it later. And you don't need to always run your own actions using shell script or something. So you can use templates. So this is the checkout template. That's mean you, once you run your CI CD in Ubuntu server, you need to have the repo source code VM, right? So you just use the checkout action from action repository. So where we defined the node JS version and stuff. And the next one is shell script. So if it is a machine, you can, once you install the node JS and stuff, you can perform this command side. So that is it. And this is a simple CI workflow will look like. Yeah. Additionally, we have one more step where we upload the generated artifacts into this particular locations. So this is a typical CD workflow. So what we do is the above step is to build the artifacts and the deploy steps are defined to download the artifacts from the directory that upload. And we are deploying to AWS. Here we have the secrets and stuff. So this is not hard-coded. This is coming from the GitHub actions built in Secret Store. So evens, we have like hundreds of events that can occur in the repository. So these are some events that can occur. So here you have a link where you can see more about what are the events that gonna trigger in the GitHub repository. So you can have a workflow which can trigger based on someone pushed or someone made a fork or you can even run cron jobs. And there are like two types of GitHub events. So one is single event. So basically this event is going to be triggered when someone open an issue in the repository. Otherwise it won't. And you can have events, multi events workflow. So basically this particular actions will be running when someone push or when someone fork in the repository. So jobs is basically, it's a combination of shell script where you can reuse it later. So you don't need to always write the shell script for all you need. So it's simple as reusing the code, piece of code. And actions. So as I said, you can use actions from different places in marketplace. So you can, I will show you how it will look like in marketplace. And it's simple as even that triggers workflows it going to run some actions. So you can automate your workflows. Here you can see some very famous templates such as deploy node.js to Azure web app and publish docker containers. So you don't need to write everything from the scratch. So if you want to publish a docker container right after you merge up your request. So you can configure this template which is available in GitHub marketplace, that's it. So we have more than 11,000 GitHub actions template available in GitHub marketplace. So you can have a look and how you can use GitHub actions. Here I will tell you some like interesting stuff. So first thing we know, we discussed about we can create the CICD pipelines using GitHub actions. Second one, you can auto label your pull request. You can have some configurations of what label need to be added if the PR contains these keywords. So you can have, you can do that as well. And you can generate lighthouse report. How many of you are front end developers? One, only one? Okay, sad. Okay. So if you are coming from a front end development background so you don't, you have to check your side scores using lighthouse which is available in Chrome. So every time what we do is we use to test the report manually so it will take a lot of time at least five to seven minutes will be there. So you can configure that stuff in GitHub action. So right after you push the code, lighthouse report will generate to you. So you can check the score there. And you can have a code quality checker. So if you are working in a strict company like me, there will be a code checker, code quality checker. So you can have a sonar keep configured over there. So if your unit test and the code quality stuff is above the threshold, your PR will be passed. Otherwise it will be failed. And as we saw, you can build containers and publish Docker images. So you don't need to remind the difficult Docker commands and you don't need to do it manually. So you just push the code, Docker image will be published in your configured environment. And sacred analysis, that's a inbuilt feature in GitHub. If you are like hard coded any secrets or if you have any vulnerabilities in your source code, it will be, you can even have an action for that. And automated infrastructure creation. So this is something what is today's and Terraform. You can create the infrastructure using GitHub actions and unit testing, linking. If you're coming from a JavaScript background, you know about the linking, right? So you can link your code automatically and you can deploy application to any cloud platform. Or we have like more than 11,000 of GitHub actions for all the cloud vendors. So you don't need to write everything. So you just use the template and go. And send messages to our notification to people. So you can configure templates. If the CI would pass, notify these people. And if the CI is failed, notify these set of people. So you can configure those stuff as well. And finally, you can even order PSAs using GitHub actions. So I have seen a company, every sprint, if the release is successful, the GitHub actions will automatically order number of PSAs for the team. So that's the condition they configure. So let's discuss about the pricing. So we have some blah, blah pricing based on the OSN, the number of minutes that you're going to run. So at GitHub, they love open source, right? A lot. So if your project is a public one, GitHub action is free for you. You can use any number of minutes for free. So I have a demo. I think I'm running out of time. So let me show you the repo where you can see the workflow. So this is the demo I had. This is a simple react application. So I need to deploy this react application to Firebase. So when someone's merged the code, it needs to be deployed into live environment. Here you can have a look once you want to do the same. And this is the live channel workflow. And the second one is our non-live. That means I have configured this workflow if someone made a poll to master branch. So as a front-end developer, I don't need to crown that particular branch and check the changes. So this will deploy to a preview channel in Firebase hosting. So when someone made a poll to master branch, so there will be a channel for that. So I can have a look at here. Once I deploy, you are generated in the PR description. So I can have a look at the UI changes there. So that's the demo. Sorry for not starting the demo from the scratch. So I'm running out of time. And a little bit, we have to go from here. If you are a student, please go for GSOC and create your own GitHub actions. If you are a Linux background person, you can create your own GitHub actions published on GitHub Marketplace. So someone can make use of it. And open source and keep contributing to the community. If you have any questions, it's a time. Yeah, but we have time for a couple of questions. If anybody has some, thank you very much, Ahmed, for your talk. Yes, please go ahead. It depends on the size of the applications. So if you are going with a free plan, there is a limit for the C power, right? So based on the free plan, on your applications, it will take some time. What language, Python or something? Yeah, Python, it will take probably with the free plan. Within four minutes, you can get it done. All right. Any questions? Yes, yes, yes, let's sort of skip those slides. So because if you have your own VM running on AWS or Azure, so you don't need to pay for GitHub. So you can configure the stuff to a VM. So the CACD pipeline will be running on your machine, your own machine. Yes, it's catchable. So, yeah, we need to install. So otherwise the code will break, right? If someone has a vulnerability dependencies, the CI will fail. So that's where we need to always do some NPM install in the same way. Any more questions? Thanks a lot again, Ahmed.