MLOPS Github Action With CICD Pipeline One Shot Tutorial

Key Takeaways

hello all my name is kushak and welcome to my YouTube channel so guys uh this video is a one-hot video on understanding about GitHub actions uh we will be understanding what exactly is GitHub actions uh it is also called as a cicd tool what exactly is continuous integration continuous uh deployment or delivery along with that we'll also see one end to end project where it'll automate an entire workflow GitHub actions is an amazing tool open source tool where many people can specifically use it whenever you're developing your endtoend machine learning deep learning project it can be any kind of projects it will be super important so we will be going from Basics we'll be implementing completely step by step we will be starting with the theoretical intuition we'll understand about each and every component and we'll go ahead Implement some amazing projects as we go ahead so yes go ahead and enjoy this particular session and if you're interested to check out my udmi courses all the links will be given in the description of this particular video These are the most affordable courses in the entire Market go ahead and check it out so let's enjoy this particular onot video hello guys welcome to this amazing module where we are going to learn about GitHub actions along with this we are going to discuss about cicd pipelines whenever we talk about cicd pipelines this basically means continuous integration and continuous deployment or it can also be said as continuous delivery pipelines whenever you are developing an endtoend project let it be with respect to data science with respect to web development or any other field this will be very important if you seamlessly want to develop uh software development workflows okay so uh in this video and in the upcoming series of video we are probably going to discuss about GitHub actions we are going to implement multiple examples so that we see multiple workflows example and how it can probably automate the entire software development workflows okay so first of all let's go ahead with the definition over here so GitHub action is a powerful automation tool I'm going to highlight some of the important things provided by GitHub that enables developer to automate task related to the soft Ware development workflows it allows for the creation of custom workflow this is really important because in the upcoming series of video we are also going to develop our own custom workflows which can be triggered by various events such as pushes to the repository pull request or schedule events this workflows can be used for various purposes including continuous integration and continuous deployment and even testing and more okay now let me just go ahead step by step and we will be discussing about why exactly GitHub actions will be very much beneficial okay so whenever I talk about GitHub action okay whenever we talk about GitHub action this is exactly a you can probably say this is a cicd tool okay which automates the entire software development workflows okay and uh whenever I talk about GitHub action you will be seeing that how we will work with this and this is all already provided by GitHub that is the most amazing thing now let me just talk about the basic differences and some of the key terms that we are going to use regularly whenever I talk about GitHub right whenever I talk about GitHub this is specifically my code repository right code repository okay you need to really remember this because I still uh there many people what I see is that they get confused with respect to the kind of terminologies that we use over here so if I talk about if I talk about if I talk about GitHub okay GitHub this is specifically my code repository now when we talk about GitHub as a code repository that basically means we commit our code over here right we commit our code over here we create branches let's say the entire project code that we are making sure that right uh we we really need to commit we need to work in a collaborative way over here right collaborative way over here along with GitHub uh you will also find different different other GitHub other code repositories like git labs and all but uh in this example in this uh in this course itself I am probably going to discuss about GitHub right so uh then the next key terminologies that we specifically use is something called as git now what exactly is git okay so git over here uh and I hope everybody may have heard about this term it is a distributed Version Control System it is a distributed version control system control system and this is super important for developers why because here you will be able to track your you'll be able to track your source code files source code files right so you may be writing a lot of code okay and let's say that you want to probably create different different stories right you want to probably solve different different use cases now in a specific project right there will be many developers who will be collaborating in a specific project right let's say I have a project over here I want to probably develop this end project now this project let's say this is my data science project okay data project it can be any project as such in this project there will be many developers who will be specifically working right so let's say this is my developer a this is my developer B this is my developer C right so we definitely have many developers who are working in the specific project this developer a may be working on some story let's say this is story a this developer B will be working on story B right this developer c will be working on story C right now when this many number of developers are specifically working right whenever we talk about this particular stories right that basically means we are developing a different module that needs to get finally integrated with this entire data science project right so this is basically how we work in a company we work in a collaborative way right we work in a collaborative way now when we are working in a collaborative way let's say if developer a has created three files right there should be a way of tracking the entire source code that is written by developer a right and uh similarly with respect to developer B similarly with respect to developer C at the end of the day when they are creating this entire data science project after probably after writing the code in the local environment what they do finally they try to commit this entire thing into the GitHub repository right so finally all your code goes into the GitHub repo right now in order to commit in the GitHub repo we can specifically use git because git will actually help you to track the entire source code files right with respect to story a story B story C and with respect to this you may also get some kind of conflicts let's say developer a is created a file called as app.py right and developer B what they did is that they pulled this particular code and they also started writing the code in app.py now what happens when they committing in the GitHub repository some conflicts will specifically happen right then we need to resolve the specific conflicts and that is where your git will be super important because it is nothing but it is a distributed Version Control not only that if you want to switch to different branch switching branches merging branches merging branches merging branches everywhere this git will be super beneficial right but at the end of the day we are committing our entire code in this specific repository that is g GitHub repository now I hope you got an basic differences of understanding what is GitHub GitHub is our entire code repository where we'll be committing our code and G it is nothing but it is a distributed version control system okay these two are the most important things now the third thing that we specifically talk about is nothing but our GitHub actions right we talk about nothing but a GitHub actions now GitHub actions is already provided by G right and it is nothing but it is a cicd tool cicd tool basically means what continuous integration so let me talk about this continuous integration and continuous integration and continuous deployment continuous deployment let's talk about this this is really important whenever you want to probably develop an end to end project okay so in order to explain this first of all I will provide you some definition so that you can refer these things okay let's see this definition okay now over here let's mark this as bold let's mark this as bold and we will just read the definition because I need to make you understand what exactly it is okay so continuous integration and continuous deployment are two key practices in modern software development and GitHub actions can facilitate both CI is a practice where developers frequently merge the code changes into a shared repository each merge triggers an automated build and testing process to ensure the changes do not break the existing functionality with GitHub actions developer can set up workflows to automatically build and test their code every time they push the changes to the repository or create a pull request so this is what continuous integration is all about don't worry I will be showing you multiple examples where I will explain about continuous integration we'll also be discussing about continuous develop deployment now once this continuous integration is specifically done continuous deployment extends the concept of continuous integration by automatically deploying the code to the production environment after it passes all the required test okay it can be configured and all we'll see we'll see a multiple practical examples how it can basically be configured okay but in order to make you understand about continuous integration continuous deployment let me just take us very good example and again we'll see that how GitHub actions actually help us to do that okay now let's go ahead and let's take one specific example let's say that this is my data science project this this is my data science project okay now inside this particular project I have three stories needs to be implemented this is my story a this is my story B and this is my story C okay so this is my stories uh that needs to be implemented when I say stories I I'm probably saying that hey we need to implement this functionalities in our data science project and let's say this particular data science project already we have developed some of the stories and this is my main branch let's consider that this line that I'm actually creating in my GitHub repository is my main branch now see this okay now first story a is assigned to a developer okay developer a let's say developer a over here so what is basically done is that if the developer a wants to start working on the story a a very good practice that we specifically do in any industry which follows an agile met software development methodology process what they do is that they try to take a branch they try to create a branch from this main branch which will be a replica of this branch and they'll create a new Branch now this Branch I will try to name name it as story a branch Okay the reason of doing this is that because I do not want to disturb the main branch over here because this main branch may have all the previous functionalities of this data science project now whenever a developer a wants to probably work on the story a which is a new story which is a new functionality to be implemented what he or she will do they will create a new Branch from this particular main branch they'll name it to story a branch I'm just taking it as an example now after developing this entire Branch what they do after let's say after doing all the coding after implementing all the stories over here they will also write something called as use cases sorry test cases right so they will go ahead and write test cases so that we will be able to verify whether this story is working or not then after writing the text cases we will go ahead and do the build in our local to see that everything is working fine and we'll also make sure we'll test something so that the previous use cases that are present in the main branch it should be working fine right now after this entire process is done once we find out everything is working fine we will go ahead and merge in this particular main branch okay we will specifically go ahead and merge on this specific main branch right now after the merging is done that basically means our story will get merged in this main branch now before we are merging there are also some of the important things that we specifically follow in this workflow okay and here is what I really want to introduce to something called as workflow because if you are merging in this specific Branch you should know that because this main branch has already it has already all the previous functionalities it should not break the previous functionalities right it should not break the previous functionalities so what we really need to do we need to run all these test cases we need to run all the test cases so that it should not break anything then we should basically build our entire project to just understand that our entire project is working absolutely fine and the third thing is that we also do some amount of testing you know this testing specifically is done when we do the deployment so I will not include it over here okay now running all these test cases and building a project can be a part of the workflow and this will only be done when we are merging this entire story a branch to our main branch because there are some of the nulls and checks we really need to do before we merge all these things because if we don't do this checks the story let's say that the module that we have probably developed if there is some problem over there if you have written a code which will break the entire previous functionalities then it will be really bad right and that is where your continuous integration Concepts will come now this is just with respect to a single developer what if I have another developer now my another developer is that this person wants to develop in story B so what he will do he or she will do they will create another Branch so this will be my story B Branch story B Branch right now once the story B branch is created again this entire story will get implemented then again this developer will also write the test cases right then they will also be doing this building entire building the artifact in the local and they will also test this entire thing in the local itself they'll also see whether the previous stories has been is working fine or not some of the common previous stories now after this is implemented what they will do next step they will again try to merge over here right merge to the main brand now when the merge is basically happening please see this okay when the merge is specifically happening let's say that there is one common file where in the developer a also has changed and developer B also has changed right developer a has written four additional lines of code developer B is writing its own 10 additional lines of code now when they're trying to merge in the main branch what will happen a specific conflict will happen right so here there are scenarios where you will face some kind of conflict within the code so you need to resolve this particular conflict right resolve this particular conflict resolving conflict basically means if two developers have changed the same file there may be that that both the codes needs to be merged before committing it to the main branch okay now once we resolve this particular conflict the next workflow that I really want to probably start over here right workflow I need to probably execute all the test cases right I will also want to create a workflow wherein we review the code review the code with the best practices review the code with the best practices right I also want to probably do this and there will be another workflow where I will be building the project so this will be the part of this particular workflow now why we are doing this so that that our entire entire process of this continuous integration and this is what continuous integration is this is what your entire continuous integration is right because in this continuous integration we are working with multiple developers and they are making sure you know that they working in such a way that even if we keep on adding any number of Developers for probably solving this data science project itself right there should be a very automated way of following this entire workflow and building our entire data science project right and that is where your continuous integration will come now let's go ahead and see the definition continuous integration is a practice where developers frequently merge the code changes into shared repository each merge triggers an automated build and testing process to ensure that changes do not break the existing functionality with GitHub action developer can set up workflows to automatically build and test the code every time they push changes to the repository and this is just one example right and that is why your continuous integration is super important okay now this is fine and here we have also seen what exactly is a workflow workflow basically means whenever we are committing something right we really want to make sure that we run some automated build and testing process to ensure the changes do not break the existing functionality we'll discuss more about the workflows and I'll show you some of the examples with respect to the workflow also now the next thing that we are going to discuss about is continuous deployment so first of all we'll go ahead and see the definition so this is with respect to continuous integration continuous deployment extends the concept of CI by automating the deployment of the code to the production environment now guys now let's go ahead and discuss about continuous deployment and I definitely want to give you an example okay let's say that committing process everything happens in the main branch okay so let's say from this particular GitHub repository main branch so this is my GitHub repository okay GitHub repository which is nothing but my main brch so from here basically developers from the local commit in the GitHub repository after resolving the conflicts okay but once our code is in the GitHub repository in most of the companies that we specifically work and multiple use cases that I have worked usually this strategy is followed you know so what they do is that they create a different different environments right so let's say this is my Dev environment this is my Dev environment this is my QA environment okay now these all environments can be different different servers it can be different different um instances okay this can be my uat environment okay and this can be my production environment okay production environment production environment now see once I probably once all the developers commit all their codes right that basically means this data science project is ready right this data science project is ready but you know that I need to deploy this project somewhere right now if we really need to deploy it we cannot directly deploy this into production right there should be a set set of steps that needs to happen because we need to thoroughly test this entire data science project now see from this GitHub repo what we do is that after let's say deployment after we probably build the entire data science project or after we build some of the Sprints right Sprints also the concept of Sprint is that we Implement some of the stories and each and every project is specifically divided into multiple Sprints right and in each print we Define like how many number of modules or how many number of stories we really need to implement and usually this we follow in an agile process okay let's say in Sprint one we have implemented three stories now we need to test all these three stories right we need to probably give our entire data science project with three stories to our QA right so that we can do the testing now before we do the testing what we do is that we probably deploy this in our Dev environment Dev environment basically means this can be our server right it can be an AWS E2 instant it can be an Azure E2 instance sorry Azure instance itself right so what we do is that with the help of continuous deployment we will be taking this entire data science repository data science content and we'll be deploying in the dev environment here we will be implementing something like Dockers right Dockers because Dockers actually help you to probably create that images and do the deployment in such a way that you don't have to worry about any issues that may be rising because of different different servers you know based on the different different server configuration now with the help of this particular Dockers we'll be able to do the deployment now what happens once we do the deployment in the dev the development team will start testing it development team will start testing it right so once the development team is tested they they know that okay all the stories are specifically working then from the same GitHub repo we can again create a separate continuous deployment mechanism wherein we deploy the code directly to our Q environment right so once we do the deployment in the QA environment then the QA team will do the testing QA team will do the testing and after the K team finds out all the bugs after all the bugs is basically released all the bugs is basically displayed in front of the developers they solve that particular thing they commit all the code in the GitHub repo again they try to deploy it in the QA so once QA Team verifies all the bugs they're good to go that basically means we are going to go with the next environment that is called as uat uat is just like a pre prod environment okay we should not directly deploy into the production environment but there should be a series of testing that should happen then again in the U environment the QA team will again do the testing and see all the stories are working fine or not okay and finally when everything works fine they take this U environment and directly deploy it in the production environment and this is your live website or live application which is running in the cloud right with some domain name so this is the entire process now you can see over here is that if continuous deployment is not there how do I take this entire project and store and probably put it in the dev right development environment I have to probably take this entire GitHub repo I have to go ahead and uh run this particular code over here entirely deploy it in our in the in this particular server do all the manual activities but with the help of continuous deployment you know if we just design a specific workflows wherein we say that hey once a person has actually committed in the GitHub repo you know once the entire project has been built then we go ahead and deploy it directly into the dev environment right we give the server details and automatically deployment should happen right then automatically we go ahead and do the testing then once this is done we will again go ahead and Define a workflow once no bugs is raised over we can go ahead with QA then U then live right so this entire workflows can be created with the help of continuous deployment right so there are two main important things one is continuous integration and one is continuous deployment okay now uh I've just given you a basic introduction as we go ahead now we are going to also discuss about two important things one is workflows workflows right we will talk more about this particular workflows I will be taking multiple examples as we go ahead to understand about this specific workflows and I'll give you with a real world example so that you can also understand it and after completing this we will be solving multiple practical examples where I directly show you how you can go ahead and probably work with GitHub actions whenever we say we are working with GitHub actions we just need to design an yaml file okay in the yaml file I will show you how to probably work with GitHub actions how you can probably create your workflows and each and everything okay so uh let's go ahead and let's discuss with the next topic so guys now we are going to discuss about the workflows okay now whenever we talk about workflows we also say it as developer workflows a developer work flows first of all we'll go ahead and see the definition and again I need to explain you with some of the examples like how does a workflow actually look at look like and what are the key stages also we'll be discussing about it right so first of all let's go ahead and check the definition a developer workflow refers to the series of Step practices and tools that a developer or a team of developer follow to write test and collaborate right so this is really important and on on and deploy code effectively the work flow is designed to streamline the software development process enhance productivity reduce errors ensure high quality output code output a well-defined developers workflow incorporate various stages of development from coding to deployment and often integrate tools for version control code review testing continuous integration and deployment so what are the key stages I hope just by seeing the definition you got an idea that uh you know a workflow specifically refers to a series of steps and practices that a developer or team of developers can follow to write test and collaborate okay so whenever we talk about the key stages of a developer workflow the first very important stage is something called as coding right in order to probably start this we really need to write a code right so the first step is nothing but coding now in coding you know the first step of developer is basically writing code itself so here uh a developer uses an integrated development environment let's say one of the example that I can give is vs code right or any text editor and then we write a code let's say in Python programming language we can probably write in JavaScript any programming languages that you that you like okay so based on this particular programming language we go ahead and write this okay now during this phas uh the developer follows some coding standards so here you'll be able to see that the developer will also be following some coding standards some best practices right best practices like best practices of writing coding for readability maintainability and efficiency right so this is the first important key sted of A developers workflow now coming to the second one it is with respect to something called as Version Control okay Version Control now you know why Version Control is specifically used why this is really important in a specific workflow right right so most of the time we uses this particular like most of the developer uses this ver control system like git right and this will basically manage the entire code base manage the code base okay this code base this git tool specifically it helps you to collaborate it allows multiple developer to collaborate right you know this multiple developer to collaborate right this is really important U because of this collaboration only you will be able to efficiently quickly complete the projects itself right now when we say with respect to the collaborating I'm talking about there will be scenarios if you have worked in any companies you may have overwritten some of the other developer codes and all right so it is really necessary to use a Version Control System I have faced multiple problems where people who do not knew about this who do not know how to work with Version Control System used to whatever effort that I have put to develop my entire stories that would have been overwritten by some of the other developer so here main thing that you should really know how to probably commit right how to uh create branches of the repository how to push the branch how to pull the branch and how to resolve a conflict this is really important resolve a conflict right resolve a conflict specifically that basically happens in your uh um code right so these are some of the important things that we specifically learn in Version Control and this is also a part of the developer workflow okay now coming to the third important key step right third important key step is nothing but code review understand whenever whenever there is a main branch right let's say this is my main branch uh over here so this is my main branch whenever a developer creates a new story whenever developer is working on a new story right right this will basically be the new Branch itself right and in this particular Branch the developer a starts working on that particular story and later on this branch is basically merged before this branch is merged right it is also a very good thing that we go ahead and do some kind of code reviews usually we do different kind of code reviews like peer code review the architect code review different different code reviews basically happen in a specific team the main reason is basically to follow the best standard practices for this particular code review right best practices that we there right and I hope you have seen this kind of code reviews and all right um let's say if uh there is a code review if there is a new review of the code that is probably given right uh based on the feedbacks we need to probably solve that and by this we will be able to improve the code quality right code quality so this is also one of the very important stage with respect to the developer workflows coming to the next one which is called as testing so let's go ahead and discuss about testing this is also one of the important key stage with respect to the uh developer workflows now you should understand I'm not talking about QA testing over here right I'm talking about automated testing automated testing now you may be thinking Krish how does automated testing basically happen specifically in the developer workflow there are multiple ways one is unit testing we definitely write a lot of unit testing unit test cases and all the second one is something called as integration testing the integration testing is basically done so that uh the previous uh stories that are development that are developed or previous models that are developed that should not break right and the third thing you can also go ahead and design your end to endend test cases end to endend test cases so that just to find out whether everything is working fine or not and since this entire automated testing is a part of the workflow so this should also be getting automatically triggered whenever we try to merge the code into the main branch itself right uh this was one thing then the fifth important workflow specifically with respect to continuous integration right CI now this continuous integration is really important because I've just given an example with respect to one developer right but in a project you specifically have multiple developers right so in every commit of the code you know we should be reviewing it we should be seeing we should be building you know we should be building the we should be building the entire project we should be testing the use cases right automated testings and all these things should be there and the developer should also be notified uh to fix the issues before merging right so it should be notified the developers should be notified uh before fixing the issues for fixing the issues I not say before fixing the issues for fixing the issu so that we can go ahead and merge it and after the continuous integration is done we already have discussed about CD that is continuation deployment after the merge is done successfully we deploy in different different environments we deploy in different environments right different servers let's say QA server Dev server Dev QA U right U prod so these all servers we specifically use so this is the entire stages with respect to a developer workflow and here the two main things is that from De Vel mment to what kind of issues that we specifically face what is the different kind of Workforce that we probably follow we can basically go ahead with this right and there are some more additional things which is called as monitoring and logging but I will uh right now I'll just conclude till CD okay now let's go ahead and see one of the developer workflow okay with a real world example so here let's say that uh one of the example that I will show you developer workflow okay with a real world example and then in the next uh in the upcoming series uh again we will be going ahead and discussion with respect to practical implementation let's say that you're working you are one of the developer you are a developer a working in a team okay for some project from for some data science project let's say for some data science project okay or for any project now let's say uh you currently in Sprint 3 you have actually got one request of a feature development right feature development okay now with respect to this feature development uh uh when you get this particular story as a developer you pick a task you pick this specific task after you pick this specific task uh it can be a bug it can be a new uh change request it can be multiple things right now once you pick up this task let say this is my main branch right main branch you try to create a new Branch for this particular story or for this particular feature let's say and you start developing this okay then this main branch that uh this this additional branch that you have uh created this you will start writing the code in your local environment okay local environment by using some id id okay then the next step uh that you specifically go go ahead once you do the development it is nothing but push and pull request push and pull request and this you usually do in your GitHub repository so pull request is basically written as PR push request right push request push and pull request we basically same right now once the development is done what happens once the development is specifically done I will take this entire thing okay I will take this entire thing I'll paste it over here once the development is done you'll be able to see that what developer will do is that from the local it will try to push into the rep remote repository once the development is done right so let's say if this is my this is my remote repository so here this is my remote repository which I have created as my new Branch since I'm doing the development in my local environment once this local environment task is done we push the code back to our remote repository okay once we do our remote repository then uh we raise a pull request pull request to probably commit in the main repository right initially we created a branches now we are raising a pull request to merge the changes in the main branch right we need to merge the changes in the main branch now before doing this uh other team members other team members will get get that request okay and they will be reviewing the pull request for code quality for code quality style and any other issues any other issues okay so they will be specifically doing this particular task any other issue right so this way they are actually uh following some kind of workflow before just committing it to the before merging to the main branch we are still in the continuous integration phase right we have still not gone to the continuous deployment right now after doing that uh the fourth important step that most of the developer follows is nothing but automated CI pipeline automated CI pipeline okay now what this automated CI pipeline does is that let's say I will give you an example once the pull request is open okay a CI pipeline is triggered a continuous integration pipeline is automatically triggered I'm just taking an example of a workflow guys you really need to understand right so here I'm just giving a theoretical example like what all things basically happen whenever you're developing a story right now what this pipeline will do this pipeline builds the application builds the application and runs all test cases runs all test cases okay now this test cases can be unit test cases integration test cases different different test cases this is one of the cic CI pipeline right here a CI pipeline is automatically getting triggered okay now coming to the third important step over here if this pipeline passes then so here if I'll say if pipeline passes passes okay the pr the pull request is approved and the code will be merged right and merged into the main branch merged into main branch now what has basically happened before merging we just doing some kind of nulls and checks you can probably understand with this automated CI pipeline right then coming to the fifth step it is nothing but continuous deployment this can also be this is also a part of the developer workflow okay in continuous deployment upon merging the pr merging the pr a CD pipeline is triggered now you need to understand something right when I'm saying this PR this PR is nothing but it is a pull request it can be a push request this is basically an event now based on a specific event whenever an event occurs a workflow is basically triggered a workflow is triggered and this workflow follows some steps some process you know let's say over here uh we are going to run all the test cases so this can be one specific workflow now in this workflow pipeline is basically triggered so here you can see upon merging the pr once the merge basically happens a CI a CD pipeline is triggered and this automatically the application is automatically deployed let's say to any staging environment deployed to Dev environment I'll say Dev or staging environment done right for further testing okay once the testing is perfectly done then later on it can be uh deployed to the production environment now why I have written all these things this is just to make you understand how does a workflow go ahead right so we started develop a workflow there was a team of data science who's working on this data science project developer a got a new feature development it probably created a new branch and it started working in its local environment that is uh considering a specific ID once the work is done then what we did we committed from this local environment to this remote repository or the new branch that we have created and then we raised a pull request to merge it in the main branch right before merging in the main branch automatically uh uh workflow got triggered to check to do the review for the code quality style and other issues right this usually is done manually okay so this code quality review and is done manually by your PR right then automated CI pipeline once the pr is open a CI pipeline is automatically triggered the pipeline builds the application and runs all the use cases all the test cases right now here this is really important so what all test cases we will see all these examples we'll also see in the practical way right we will Implement these things all test cases okay we will see this with an example as we go ahead right if the pipeline passes the pr is approved and merged in the main branch so here you will be merging this in the main branch after the merging is done this continuous deployment pipeline will get triggered so this in short is We are following a specific workflow what is triggering an event specifically on a specific event a workflow is basically getting triggered and based on this triggering right something is basically happening right it can be building testing use cases it can be deployment it can be multiple things it can be even updating your readme file it may be updating the version number of the readme file anything it can happen right and all these things are basically happening right and this is what we basically do right we build we test automatically all the workflows will get triggered see if GitHub action is not there right we really need to do all these activities manually which is really bad right because we really want to focus on the coding part all this nulls and checks can be actually automated with the help of GitHub actions and that is what we basically do right now let's talk about some of the benefits uh of using all these things right so here you'll be able to see I've written some of the benefits okay the first benefit improved collaboration right clear workflow and process facilate better collaboration among other team members High code quality code reviews automated test cicd practices help to maintain a high standard quality then reduced errors automated testing and deployment reduce the likelihood of a human error faster delivery streamlined workflows can enable faster development and release cycle which is really important that is the reason we follow this agile process everything continuous feedback roup regularly monitoring and feedback helps team quickly identify and address the issues so these are some of the benefits of using this specific workflow which you can actually check it out over here now as we go ahead we will be seeing more practical examples wherein we will try to create a developer workflow directly in inside our GitHub repository and uh I will show you how you can actually do that okay so let's go ahead and see that so guys I'm super excited now to show you the first practical implementation of the GitHub action workflow here we are going to create a python project and with the help of GitHub action we are going to do the automated testing you know with respect to the unit test cases that we specifically write now what are steps are basically required I will go ahead and show you step by step please go ahead and follow the steps so first of all go to your github.com and here I will go ahead and create my new repository let's say my new repository name will be GitHub action uh GitHub action let's say I'll write test GitHub action okay and uh this will be with respect to python app so app GitHub action I will go ahead and write and uh no need to select anything like read me file and all so I will not be selecting any readme file or any license I will just go ahead and create this specific repository okay once I create this repository you will be be able to see all these things okay now uh let me do one thing let me go ahead and open my vs code right so this is my vs code I will go ahead and open my terminal now with respect to this terminal uh here I will just go ahead and open my command prompt I will delete this okay um you should have git installed so that you can get basically get started so what I'm actually going to do is that I'm going to go ahead and create my readme file readme.md file so let me go ahead and create this over here so I will write read read me do MD file okay so this will basically be my readme.md file I'm just going to create with the same notation over here and here let me go ahead and write this is the python app okay okay just to write some information in the read me file right so once this is done the next step will be that I will just go ahead and copy this particular command that git in it so that we can initialize the repository I'll go ahead and paste it so here you can see initialized empty git repository in this particular uh folder right GitHub actions example dogit so here you'll be if you go into this particular folder you'll be able to see uh dogit folder right so this is what it is basically initialized uh git Lo repository over here right so once we do this specific thing the next step what I'm actually we going to do over here is that I will go ahead and add this particular file that is readme.md file because I need to commit this specific file right so let me quickly go ahead and write get add dot so that basically means it is going to add all the files that is available so here you can see it is in the added mode index is basically added over here and then we will go ahead and commit it with our first commit okay so we have committed this particular thing in our remote repository and then we are going to probably create a branch that is with the name of main I'll go ahead and execute this perfect then we are going to add the remote repository origin just by writing get remote add origin this all values so I'll will go ahead and quickly execute this okay and finally I'm going to push all my data inside this particular origin from origin to the main right so once this is pushed we all good to go now if I reload this my read me file will be available over here okay so this is the basic step and I think we have already covered this in git tutorials and uh I've explained each and every step step by step right so once this repository is basically created I will go back to my vs code and I will start writing my code okay so first of all I will go ahead and import my or create my file which is called as requirement. txt now inside this particular file you know uh I will just go ahead and mention some of the libraries that I'm actually going to use for this instance I'll just use two libraries one is pandas and pest okay now pest test is specifically required over here because we need to do the unit testing and with the help of P test if you have some basic knowledge with respect to python the unit testing can be carried out with this particular Library called as pyth test okay so I'm going to use this particular library and uh I'm going to save this okay now over here what I'm actually going to do I'm going to go ahead and create my simple python app inside this Source folder and I'm also going to go ahead and create my test cases right inside this particular folder which is called as tests and I have to use specifically test folder because what py test does is that it looks inside the entire code repository where test folder is there and from that it will probably pick up all the py file with respect to the uh test unit test cases that you have specifically written okay now inside my source folder uh I will go ahead and create my init file so that I will be able to import this wherever I really want okay whatever packages I'm trying to create inside this then I will also go ahead and create my another file which is called as mathor operations. py let's say this is the operation file that I'm actually going to create over here okay now once I do that uh I'm just going to Define two simple operations one is addition and subtraction so I'll create two function definition addition a comma B return a plus b and definition subtraction a comma B which is nothing but returning a comma B so this mathscore operation. Pui file has this two functionalities with respect to this two definition now similarly if I really want to go ahead and write my use cases so here inside my test use cases first of all I will go ahead and create one more file which is called ascore uncore init.py okay and along with this I will create one more file which is nothing but testore operations. py okay now inside this test operationore py I am going to import both this add and subtraction function in order to import it how do we import it in a modular coding I'll go ahead and write from SRC dot uh do um maths operation I'm going to import add comma subtract right so I'm going to basically import this two function that is ADD comma subtract okay so add and subtract is basically imported I hope that is the same function name okay now we will go ahead and create another function which is called as testore ADD and this will basically be my test cases which I'm actually going to run over here so if I go ahead and write assert okay assert of add 2 comma 3 so my 2 comma 3 output should be five right so this assert statement is basically going to check whatever output that I'm actually going to get from this particular function is it equal to this right if it is equal it is going to give me true okay similarly I will go ahead and write assert with respect to add and if I just go ahead and write Min -1 comma 1 right it is again going to give me zero I can also go ahead and write with my other function that is subtraction where I'm going to write 5 comma 3 which is going to basically give me two so it is just going to check this three different use cases since I've created another function for testore add let me just remove this okay and let me create another function uh for subtract so I will say test underscore subtract and this is my unit use cases that I really want to execute it right so here I'm just going to go ahead and paste this similarly I will go ahead and paste some more assert statement so that it is going to check all the unit Cas cases okay so here uh if I go ahead and write uh 4 comma 3 this is going to give me 1 if this is 3 comma 3 it is going to give me zero so this functionality should be working fine right if I give uh five or 2 comma 3 it should be giving me minus one okay so it is basically I really want my P test library to check this specific use cases and see if it is working fine with respect to the functions that I've actually created okay so this looks perfect two folders one is Source where my operation is there one test folder which this py test will be specifically looking at it okay now once this is done what I will do I know this will definitely work I'll not execute even in my local I will quickly go ahead and Commit This okay so let's go ahead and Commit This so I will write get add dot okay then I will say get uh commit minus M um unit test cases updated updated okay and I'll pre