Project & Branching Explanation For Interviews | DevOps Shack

Let us start. So we'll start everything from scratch. Let us say that you joined a company and there is new onboarding happening of a client. A client has also joined your project uh joined your company so that they can get their project completed so that the project works fine. Right? So after everything is done, first thing that is going to happen, client is going to provide information. This is what needs to be done. So let's say we have multiple parts. There will be parts like we have to set up infra. There will be separate team team for doing development of the source code. There will be team for devops. There will be team for testing. There will be other teams. But from technical point of view, these are the main teams that we need to understand about how exactly they will start working. So for each of the team members, for each team, there will be tickets created. Okay, if I show you an example of it, So, Jira is one of the platform where you can create and manage tickets. Okay, let me show you an example. So, let us say that there are everything that needs to be done, it's going to be done with respect uh with help of tickets. For example, let's say infra tickets have been created. First ticket one inside which task is mentioned that you need to set up an EKS cluster. There will be other tickets also you need to set up like let's say uh servers like sonar cube similarly for development people tickets will be created let's say D1 ticket where it is written that you need to write the [clears throat] source code for the whole application so team members will start writing it right if I show you example of it how does it look okay so I hope you can see this clearly so there will be this board canban board it is known as here you can see in first section we have to-do list here one we uh one task is given deploy feedback page uh feature to QA for testing right this is our task because we are going to be doing the deployment similarly there will be tickets like for developer create source code for feedback page okay so let's say this will be for developer and it needs to be assigned to someone as well. So once you click on the ticket sorry there will be proper description there will be some uh assigne like who is going to work on it for example let's say I'm assigning it to myself that means let's say I'm a developer so I'm going to start working on it right due date and other information will be written so tickets will be done like that and let's say developer has completed their tasks or they are working on it so they are going to move their ticket to in progress state Okay, next question. You might think why do we need to have ticket system in order to uh like work. So basically with help of tickets work can be work progress can be tracked. Anyone who want to know what exactly is going on manager or client who want to see key what is the progress on my given task. So they can see the information within the tickets. Right? Plus people can log in their hours. For example, let's say I'm working uh 9 hours a day. So I need to mention I can mention key in my current ticket. Let's say I have ticket T1 assigned to me. So I can mention key I worked on this ticket 6 hours. So 6 hours will be logged for me. Right? So tickets are very good way of tracking the work progress for logging our effort like how much we have done and how much is spending those things and this is the main thing. So this is how ticket like tickets will be utilized for uh tracking the work. Next step comes. Let's say client says I want to add a new feature. feedback page on my website. Right? So this task has been come. Let's say this ticket got created. Now what is going to happen? Developer let's say developer day one he will pick up the task. He will become the assigne of the ticket and he will start working on it. So how exactly developer it? For that we need to understand a little bit of branching strategy. Okay. Also guys uh if you have any questions after the session I'll be taking questions. So meanwhile you can send the uh send your questions here. Okay. So let us understand like how exactly developer is going to start working with the task given to it. Before that we need to understand about the branching strategy. So some of the common branches that most of you might already know we have main branches we can have QA Dave branches we can have PPD branches right or let's say DR branches as well but in reality do we have these many branches in reality no

why because see the thing is let's say you are working with a small project okay small plus it is an internal project that means its target audience is us the teammates so in this scenario having these many branches is not very useful because it's going to be very hectic also to manage things. So how many branches we are going to have? First we'll be having one main branch which will be utilized for deploying the application to production environment. Second we can have from main we'll be creating a QA branch. Okay. So let's say now QA branch is created. Now whatever development testing everything code will be done here. So task was given by uh client that we need to add a feedback page on a website which is assigned to developer one. Right? Now developer one is going to create a branch from QA which is going to call it as feature format will be something like this feature/ feedback page. Okay. So this branch is created from QA and it is created by developer. So once this branch is created what is going to happen? developer is going to clone the repository on their laptop on their office laptop and in the local laptop in this laptop they are going to start writing the source code. Let us say that developer has completed the writing the source code. Next thing what they are going to do they are going to run their source code on their local machine. That means on this laptop only before they push the code on the remote repository like on GitHub they are going to write the source code locally and they are going to perform a local run of the code so they can confirm my code written is correct. Now note that here developer is not concerned about how many bugs could be there what kind of issues are there primary focus is that they are just going to make sure the code that they have written it is working. Okay. So once developer has uh like locally ran the application it is working fine. What they are going to do? They are going to push their code inside feature branch from local machine on the remote repository. In feature branch they are going to push their code. Okay. Once this is done then they are going to raise a PR. PR means pull request. They're going to raise a pull request. Basically they want whatever code they have written here they want to merge that code to QA branch. So for that they are going to raise pull request. Pull request is it's not like that key they just raised it and it's done. No they are going to raise it then there will be some approver and reviewer assigned who's going to review the code that is written correctly or not and there will be one person to approve this merge. Okay. So once reviewer has confirmed okay this code is working fine kindly merge it then it will be merged to QA branch. Okay. So feature branch is merged back to QA branch. Next thing what is going to happen now inside this QA uh branch uh the code is ready that we want to deploy. So what is going to happen? We want to deploy the code to environment. Now before we talk about environment let us understand about like little bit more uh in detail about what kind of environments we'll be having. So again generally you might have key you might have and for now uh as per the environment just understand environment is like a cubernetes cluster. Okay. So there will be one environment for Dave inv there will be one for QA one for PPD one for prod and one for DR. So basically I'm trying to say that there will be five cubernetes clusters right where in this cluster what we are going to do we are going to perform deployment of things. We are going to develop new feature and test it here in QA environment. We are going to deploy the code to perform uh basically security kind of testing. Find what kind of bugs we can have. PPD is like this similar to prod but it is an internal. Here we deploy the application just to find out how the application is going to behave when it is deployed to prod environment and prod will be the live environment where uh once you deploy the application here then that application will be accessible to the target audience. Target audience like let's say zomat application is deployed in prod environment. So it is visible to us. Whatever changes deployed it should be visible to us. Then we have DR which is for disaster recovery. If something goes wrong with the prod environment, we can deploy the application to DR to reduce to make sure there is no downtime. But you can understand here if you're having five clusters, five environments separately we are keeping it's going to be very costly. It's going to be very hectic also to manage these many environments. So in reality when you talk about companies what they prefer to do they will keep just two environments one QA and one prod. In QA they are going to perform all the Dave environment task, all the QA PPD environment task. Okay, all these things will be done in single cluster. Once everything is done

then application will be deployed to prod environment. So this is a better option. Why? Because first of all, it's not going to be costly as compared to the five environment structure. Secondly, it's not going to be very hectic. Okay, it will be much easier to manage. So here also let's say the new changes the new feature that was written by developer tested locally now it is a PR has been request once everything is fine approver is going to approve the merging and this uh this branch will be merged to QA and after that generally we delete it some companies will keep the branch but generally we used to delete the feature branch once it is dep once application is deployed here what we do we merge it to uh we deploy it to Q environment Okay. So once application has been deployed to Q environment, what is going to happen? Testing will be done. Testing by testing team, separate team will be there who is going to start testing. Now they are going to see if they find any bugs. And let us say they have find bugs. If they find bugs, what they are going to do? They are going to inform to developer. Okay, there are bugs available. Kindly fix it. Now developer is going to create another branch which is going to be known as bug fix. and they are going to write the source code test it locally and then again raise the PR to merge the bug fix branch back to QA again once changes are approved merge has been taken place again we deploy to QA environment and testing team will start testing again okay testing started now this time no bugs were found by testing team so testing team will give a sign off key right now or your co your uh code is having no bugs and Now you can proceed with deploying it to the main uh prod environment. So once now at this point after merging feature and bug fix branches that we can make sure that QA branch is having the latest code and there are no bugs in it. Right now that is done then from QA we are going to raise a pull request to main branch. This is also going to be approved properly. Once merge has been taken place it's going to be deployed to prod environment. So this is the branching strategy that we use. But now let me explain in very much detail the pipeline flow. Okay. In this anyone having any doubt you can ask you can I believe you should be having some uh option to raise request to raise uh to uh create a request to raise your hand. So if you want to speak if you have any question you can ask quickly or we can move to next thing. Okay, no questions. Then let us move to next thing. Now, so basically I have created multiple diagrams and let me explain you with respect to that. So a general format we understood as of now that uh deployment will be done from QA and like what branches we'll be creating from QA feature branch and if any bugs are found then bug fix branch will be created code will be fixed and it will be merged back to QA deploy to QA environment testing will be done if bugs are found create bug fix branch again if no bugs are found then sign off will be given by testing team now let's talk about what will be the stages in our pipeline this thing that you that this thing that I explained Let me go a little bit deeper so that it makes proper sense. Okay. So this is the diagram. Okay. Also guys one thing I would highly recommend you whatever you are learning here if possible try to implement it because you know when you uh learn things theoretically it's really good for understanding but from interview point of view I would highly recommend that you make sure that you are actually implementing it as well. Okay. Now let's talk about how exactly will be happening. So first feature branch will be created and Dave is going to commit the changes to feature branch right and see before changes are pushed to feature branch developer is going to make sure they are testing the application locally also then only they are going to push the source code to remote to GitHub repository on feature branch. As soon as it is done then PR will be raised. Okay, PR is approved. Then this feature branch will be merged back to QA. And in our pipeline, we have set up trigger events. Trigger events basically define key when exactly and how exactly your pipeline will be triggered. So let's say I have written QA branch trigger event that when push is happening to QA branch pipeline should be triggered. Which pipeline? QA pipeline. Okay. What is going to happen here? So, first stage in our pipeline is git leak scan which is going to scan the whole source code to find out if there is any

kind of sensitive data. Sensitive data means there is possibility that some junior developer might have mistakenly added some kind of API key, some kind of token, some kind of credentials which is not recommended, right? So, GitLink scan will be able to find out that information. Are any kind of secrets or sensitive data is added to your pipeline or not? If added, it's going to let you know where exactly it is added. Then we are running five stages, but we are running in parallel. Why we are running them in parallel? Because if you run them in parallel, it's going to save lot of time. Okay. So here five stages we are running. First three stages you can see we have written check TF, check of K8S and Czechov docker. What exactly is first of all what exactly is a Czechov? It's another security tool that is specifically for kind of things. First is Czechov terraform scan. So inside our project in case we have terapform files, Czechov is going to scan all those files and it's going to tell you if for example let's say I have written main dot tf the terraform uh configuration file. So if there is any kind of misconfiguration then check will be able to tell you what exactly is the issue and how to solve it. That is the best part. It's going to let you know where exactly is the issue and how to solve both the things. Similarly, it's going to do it for Kubernetes YAML manifest file. If any misconfiguration is there, if any if you're not following best practices, it's going to tell you that. Similarly for Docker file also, let's say sometimes you know when you create Docker file by default, we don't create a user inside docker file, right? So uh by checkov it's going to check and it's going to let you know that you do not have a separate user for running your application inside the container. Those things will be given to you. So check off is going to help with these IC scans. Then we have TV file system scan. Trivia file system scan is mainly going to focus on dependency file. What are dependency file? These are the files that contain information about what are the libraries going to be utilized within the project. For example, for Java, we have pom. xml. For NodeJS based application, we have package. json file. For Python, we have requirement. txt. Forn net we have croj files. These files will contain information about what dependencies are being utilized. So, next stage is uh next stage we are adding which is going to be file system scan for client front end server backend. So it's going to see for example it's a in my project I'm using dependency XYZ but there was a specific version of XYZ dependency let's say 1. 1 which is not suitable to use which is like vulnerable or having any kind of issue. So Trivy can find that uh find that information key this dependency is being utilized in your project and is it is not suitable to use. Best part is that Privy is also going to give you a solution. Instead of using 1. 1 version, kindly go ahead 1. 2 or something bigger. Okay, that means either 1. 2 or bigger version because the issue was fixed in 1. 2. Okay, so you know these second stage these five stages that I'm running in parallel, they are going to make sure key uh there are no uh sense to data in your source code. There is no uh like wrong dependency you are using like vulnerable dependency you are not using those information. One more thing one thing you can see I have added them in parallel. What is the benefit of running them in parallel? For example see we have Czechov TF Czechov Kubernetes and Czechov docker and client files TV file system scan and server TV file system scan. If I run them individually one by one that means first I ran this then I ran this in that order then each of them might take minimum 30 seconds okay so now our pipeline these five stages will be completed in about uh 1 minute 2 minute 2. 5 minute but if I run them in parallelly then each of them will be started all together and all completed within 30 seconds so you can see that you can actually remove the time you can decrease the running time of your pipeline. Okay. Now this is this point you should note everyone I would recommend highly to note that this point you can actually add in your resume highlighting that your work actually reduced the pipeline time duration. Okay you can mention that your pipeline became faster. Okay you know for example at this point in resum it is recommended that you should be adding quantitative measures. For example, after your work pipeline became

30% faster. So this is the way that you can explain that. Okay. Now coming to next thing. Next thing we have linting. And linting also three uh three stages I'm running in parallel. What I'm doing? First of all, what exactly is linting? You might have heard about sonar cube which is going to help you find bugs and other issues in inside your source code. Just understand linting is the lighter version of that because see lint in using linting you can find some information where exactly issue is there inside your source code it may not give you solution but when you use sonar cube it give it's just bigger version of uh linting it's going to help you find out all the issues in your source code plus it's going to give you solution also so for front end I do first then back end and whatever unit test cases are written for our uh source code that also we can execute This also I'm running in parallel so that instead of 1. 5 minutes they should be completed in 30 seconds. Right. Next comes the part next stage we have sonar cube analysis. Also guys one very important thing I want to tell you uh with respect to this project. So you know uh one of the most common thing that most people get stuck is something that like how exactly code application promotion happens. See deploy deployment to uh one environment is fine but obviously you know key first before deploy to production we have to deploy to lower environment. So I'm going to explain that as well how exactly promotion is going to happen. Okay let us understand this part then sonar analysis what exactly it's going to do? It's going it's a static code analysis tool. Static code means your code is still not in running status. It is kept in GitHub. That means key whatever kind of issues your source code may have for example it can have bugs it can have vulnerabilities it can have code smell these kind of things. So sonar cube is going to help you find these issues and give a solution to it also like how you can remove bugs and this part also you can mention in quantity measure that we started I integrated like individually you should say that I integrated sonar cube which reduced the bug resolution time by 30% or 40% like that you can mention so in this way you also in this way you'll be able to add quantitative measures right another thing that sonar cube does is check the code compliance What exactly is code compliance? Let's say in my company I have written like we have decided that our code should be accepted for deployment only if it has zero bugs and certain other conditions we can write. Okay, we can say that only if 80% of the code is tested. So these are the thresholds that we define. Sonar cube is going to check your code against these thresholds. these conditions. If these conditions are matched then we can say that code is in compliance and it is accepted then what we do then next stage is going to be building the uh front end. Now here you might think Adita why you are building front end here. This is this whole flow that you are seeing. This is one of my course project. It was NodeJS based three tier project inside which front end is going to be built to create a package known as bundle. js which is going to be the run uh which is going to run the UI on browser. So even though we are going to build the front end part inside the docker image, I'm still running it here. Why? because I want to make sure key there is no issue inside the front end build because here it's going to build and if it fails here then there will be issue. So I want to first make sure before docker build starts we can verify that okay front end build is working fine. If it is not working fine it can fail here itself. Okay. Next thing we are building our docker images. Front end docker image and back end docker image. We could create we could use a multi-stage docker file to make sure that we have a very smallsized docker image. Once we have built docker image then we can scan the docker image for vulnerabilities using trivi. Next thing we can do which is sbomb. Sbomb most of you might not already know it is uh something that I have seen like not a lot of people teach but this is something that every single company uses. First of all what it is short for software bill of materials. Okay software bill of materials is going to do what? Basically, you know, when you want to set up sbomb, you'll be needing multiple tools to do that. What it does first, it's going to find out whatever text stack being utilized in your project, whatever libraries are project. Every single thing it's going to make a note of making, it's going to create a report inside which it will be mentioned what kind of test tack, what kind of library you are using. Second tool is going to do what? It's going to scan that report and it's going to let you know if your project is getting is having any kind of issue or not. How this is beneficial? For example, let's say some global issue happened. Globally some kind of dependency is having a very big issue.

How do you figure out figure it out that your project is impacted by it or not? That you can understand by using sbomb. Sbomb is actually going to tell you your project is also impacted by this global issue. So you can understand from security point of view how important this is. Once these tasks are done then we are going to move to next thing which is push the docker image and then we are going to update the docker image tag in our kubernetes yaml manifest files. Okay once it is done then we are going to deploy to QA environment. Okay QA environment. Note that I'm deploying to first environment. Now once we have deployed then comes the next part. In next part what happens once deployment is done to Q enving team. Testing team will start working with the deployed application. It's going to figure out if there is any kind of issue any kind of bugs present or not. If bugs are present then from QA branch we are going to create a bug fix branch and developer are going to write the source code to fix the issue. Once they have fixed the issue in bug fix branch, it will be merged back to QA branch and as I told you in my pipeline I have written if any push happens to QA branch it is going to trigger the pipeline. So once pipeline is triggered again it's going to execute all the previous stages that I told you and again it's going to deploy to testing team. Testing team again will start the testing. If there is no bug found it's going to give Q sign off. That means key there is no bug found. And now you can proceed with next step. Next step what is going to happen? Now we are going to merge the QA branch to main branch. Once you merge to main branch so inside main branch also we have set up a trigger that whenever push happens to main branch it should trigger the pipeline. Now the best part is that key previous pipeline the QA pipeline we have already written CI and CD part. In CI we have performed all the security scans and build our docker image right and then we did the CD. So do you think at this point for prod also we need to execute CI? No. Why? Since we have already done that same code, why we need to run the CI part again? No, we don't need to do that. So inside the prod uh pipeline, we are going to do what? Whatever docker image we built previously. Let's say my docker image was ai/ app and let's say it was something xyz tag. What we are going to do first thing inside our prod pipeline we are going to download this image because this image is secured already all the scans have been done we have deployed and then we confirm okay this image is secure and this is perfect for deployment so what we do we download this image and we are going to rettag it we are going to rename it something like this prod xyz that is being done here and once we have done that we are going to push to docker hub registry or any kind of registry that you want you can use that and then we are going to update this tag inside the prod manifest file. We are going to update that here. Okay, once the Kubernetes YAML files are updated then we deploy to prod. Once it is deployed then the application becomes live. Once application is become live. So this is you know this is how promotion will be happening from lower environment to higher environment. Okay. But once had once application has become live it does not mean that it has been completed still what is pending monitoring part. Okay. In monitoring also like what things we should be using what kind of monitoring we should be doing to three kind of monitoring that I would highly recommend for you to test. First metric monitoring where you can monitor the application parts resources like how much CPU, how much RAM is being utilized, how much disk usage is uh utilized. Those things will be metrics. Second things you should be covering logs, application logs. You should be able to monitor so that if any uh any issue is happening or going to happen, we should be able to figure it out using the logs. Third thing that I would highly recommend is tracing. Tracing is what? Let us say that we have a micros service application which has multiple microservices. Okay. 1 2 3 4. So if a request goes here and it comes out here, let's say generally it takes 30 seconds. But at some point or after like some days what is happening when a request is going to our application and goes through all microservices now it's taking around 5 minute. So how do we figure out where exactly is the slowness happening. So for that we use tracing. When you use tracing then at every micros service how much time was how much time request took

it will be given. For example, let's say here it took 1 second. Here it took around uh 5 seconds. 3 minutes. So from using tracing, tracing can be done. I'll tell you in a bit. So 3 minutes. So if we are able to see that on this micros service it is taking lot of time. So we can figure out the issue might be here. So we can check the logs of this micros service and then we'll be able to fix the issue. Right? Talking about what kind of com like tools you have to use with respect to this for metrics you can use Prometheus with node exporter for logs you can use low key for tracing you can use tempo okay now you might think yita this flow is quite seems easy but in reality if I tell you there are lot of many things that you need to understand okay till now anyone having any questions you can ask. Yes, Zah. You can ask Can we automate everything all Dev Sec tools in pipeline? So, uh yeah, the pipeline that I showed you, it's an automated pipeline only. So yes, we can automate it. Also let me show you one more project that I'm actually working on for my ongoing course. So this is one of the Azour deos project. This is also purely written in YAML. I'm still working on it. Uh this is also properly automated. One more thing you should know guys, you know, uh how to do container promotion pipelines based on version as well as environment setup. How do you contain promotion pipeline based on version? Based on version, see if you are going to be using uh are you referring to the version as the tag or something else? If you're going to be like if you want to work with application versions then tags should uh will be given manually. If you're just like let's say I'm working on version 3. 1. So there you have to see in tag also if you want to use specific versions then again let's say my application is currently on 3. 0. I want to upgrade it to uh upgrade it to like uh 3. 1. So there you have to uh you have to manually provide the tags which tool we use for tracking. tracking which tracing you are asking or something else for tracing we could use uh tempo for uh for ticket tracking you could use uh Jira can we share this project as actually uh actually worked like that in interviews is it prog so yes it is prod grid and the way uh I I'll come to that as well in a bit how you can explain this in rum uh interviews see one thing I would highly recommend that let's say key uh one thing that you can actually mention you can mention things like that I worked this was an internal project where I worked it but you know to everyone I'm saying before you add this project in your resume you need to make sure that you have actually implemented it okay hi after docker image tag how it will pick the new image is there any way to automate uh you could maybe provide a little bit more clear are you saying that docker image is pushed to QA repository and we want to pull it for uh prod repository So same thing we could do docker pull command will be enough but you need to make sure that you have provided proper credentials automation you will be there or your docker image uh after docker image tag how it will pick up yeah so this example I I'll tell you this docker image tag how it will be automatically pick up the way that I set I have set up let me explain you so whenever I am building QA docker image what I do I create two kind of tags. One tag will be the commit such a and latest. So at one point let's say I'm building I'm run running my QA pipeline to uh I'm build docker image. So these two there will be two tags I create both the tags will be same commit s and latest same. So when I'm downloading the when I want to promote uh promote this image to production what I do I will download using latest because latest will be always the latest version of the image that we have built. Okay. So once I have downloaded latest one then I can retag it. That's why I keep two uh two versions of

images. uh I have four as certification how I have been working as devel so for that you can send a mail to like office devops. com we can connect separately one to one uh uh see azure devops project is actually for batch uh latest batch so I believe by this week it will be completed because again it's a very long project yes parikhit S this I believe Sai you are already in batch 13. So you can separately send a mail we can connect. So there I can explain in detail how many projects I need to keep in my resume for over three experience in uh 3 years experience in one company. It does not matter number of projects. Even if you add just one project, it's fine. But my recommendation generally what I try to say that uh what I would recommend to say that you can mention that you have been working as a shared resource. Uh this helps you to add like multiple projects in interview question asked how do you manage SQL Mongod database? How do you set up pipelines for it? You know we can make a separate video of yeah bro. So for this we'll have separate session on like how we manage databases. A for those who want to implement this project actually I recently launched my Udemy course uh so I think today or tomorrow till that time this project is uh running a discount okay so uh you can check it out you know I'll tell you like what exactly I have done and how exactly I have built this project this is quite long a long project because it took me around like the video that I created for it is around like 9 hours where I explain from scratch like everything parish very long message you are taking typing guys you can raise a request for unmute yourself you can actually instead of typing long messages you can actually speak to me here like there is there should be an option request uh request to speak. Yes, Pikshit, I have invited you. Parish, you might have received an invite so you can speak from there. Uh is Azour projects also going to be published on Udemy? As of now, it's not completed but we'll see bro. Uh Udemy course different that bad than batch 13. Udemy course is basically a 9 hours course uh with respect to just one project but that project is end to end and that project is already added in batch 13 as well. In batch 13 it is added as final project. So you can check it. One more thing I need to explain to you quickly. So guys, you know, uh while building these kind of pipelines, one thing that I would highly recommend is that you understand how you can connect to a EKS or AKS or any Kubernetes cluster because one option is present like that. You can provide credentials, you can use service accounts, you can use uh tokens but they have lot of limitations. A better or modern way uh ways that I try to use in my projects now oidc authentication. Why this is important? Because it is a secretless authentication. That means the connection to your cubernetes cluster is the most secure. You are not at all adding any kind of uh sensor data vault. But what exactly your question suam when a 14 batch I have not yet decided because uh AI part is pending in 13. So once I have added that then I will launch the uh 14 batch. Yes Ravi we will soon announce. See because you know uh the batches are

becoming like quite big now. Uh basically at this point we have 150 plus hours of content. So and we are continuously adding AI also. So yeah it takes a little bit of time to like properly launch. Yes. Uh so for secrets you there are multiple option available. One option is that you could use Hashikor. Second option you could use uh AWS secret manager and third option is you could use Azure keyword. Let me show you one example of uh this one Azure uh AWS secret manager how you can uh store your secret and how you can pull it in your uh in your pod. See this is the diagram I created like how you can uh first you know what you have to do you have to uh go to AWS secret manager store your credentials then you have to create an ESO okay external kind of operator you have to create separate service account you have to create you have to like in simple words you know the whole thing that we want to do uh we what we do like let's say I'm inside the inside as secret manager I have stored a secret then what we do create a rule, give it proper permissions, then only the secret will be utilized within the project. Okay. So, see for secrets anything you can use on which platform can you apply for job because of 90 notice period. See, for 90 days notice period, this thing is something that uh everyone is facing and reality. I'll tell you what I used to do when I was giving interviews long ago. So that time I simply used to say that I'm serving notice period and in no. com I used to write my last working day as 90th day and every day I used to update it to 90th day. So that at least my profile should be visible to interviewers key okay someone is serving notice period because they are going to filter out candidates who are serving notice period. Everyone has the requirement that uh they have to hire immediately. DB insertion where we can add and how we can proceed with insertion roll back DB insertion you are asking like uh database connection to your application correct me if uh that's what you are asking yes so uh see database connection to your application first thing you should be setting up a uh stateful set for your database multiple pods will be there multiple uh volumes will be like each pod will be having separate volume plus you can decide at a time which pod will be utilized. Okay, these things will be there. Uh so stateful state is the best option for deploying resources to EKS from pipeline and how are we accessing are we using so to EKS? Yes, Nils. So uh Githops Argo CD is also a good option but OIDC is a little bit different and but when we talk about uh like the most secure option in Argo CD also uh is okay Argo CD is also really good option. OIDC is also like you can say those are two different things. Argo CD is that key automatically EKS cluster is going to pick up everything from your repository. OIDC is something that you are deploying to EKS directly but without using any kind of secret like externally you are not at all exposing any kind of secret. So both the methods are good deops upgrade bro. Uh at this point I would recommend uh cloud you should be having good devops uh cicd proper knowledge you should be having and AI part in my opinion MLOps and agentic these two options are really good. These two things should be good. Suppose we delete to the pipeline by mistake what will we do? How backups work into our infrastructure? Srijit, it depends on like uh where exactly you are keeping your pipeline. If you are keeping it in genkins, make sure you are keeping a backup of genkins. If you're keeping the pipeline in GitHub actions, then inside that uh like since it is inside repository, then through commit you can just get it back for YAML any official docu site for documentation. Nin at this point I would recommend uh you could use uh GPT or any I platform for getting the YAML templates that is like best no for AWS like pipeline and code build I'm not using because you know I uh most companies actually are using some like old companies genkins new companies GitHub actions gitlab CI/CD and Azure DevOps only so these are the like much better options with CI/CD tool use more company most company. So bro uh like previously most companies were using genkins at this point also like legacy projects and very old projects they are still using

genkins any new project that is coming they are actually utilizing this one they are uh utilizing uh GitHub action gitlab cicd and azour devops at this point. Yes. So Nils I think you are already in batch 13 where I so in the uh final project I have actually showed how exactly you can set up arbback on the cloud level because you know when we are trying to connect to EKS cluster what we do we create a role first we create then we put the role inside EKS cluster and then we give the role the permissions to deploy but while giving permissions we define that this role will have permissions only inside a specific name space. So like service accounts if uh can be skipped also if you're using YDC the one the method that I have shown there you don't have to create service accounts uh bro how to send request to unmute here I'm not sure because this is the different kind of uh channel it is a stage channel like other channels are voice channel I just created it today so I'm not sure in most job listing azure is mostly preferred in India as I have knowledge of it was real life scenarios as they not consider web. I would recommend in Azure also at least try to build one YAML pipeline not many just one so that at least uh if you get uh options if you get any like opportunities for job then you can at least mention that you have experience in writing this CIC department for Azure also just one project it's not big for example like I'm also making one project I think it will be six or 7 hours but at least one project you should have like AWS is your primary field that is fine but one project in Azure also you should have do you recommend us getting dev uh so I don't recommend roi you should be getting dev sec ops certification for ca those things is fine but for specifically for dev sec ops I really I wouldn't recommend uh where as of now it's going to be posted in my like uh current or next patch but uh maybe on Udemy also I'll post soon see because at this point I have created just one project for Udemy uh Hopefully it's running good and if I try to show you like what exactly I have covered. So first of all you'll be learning how to run how to create the CI/CD pipeline where you can promote your application from QA to production using GitHub actions. All the div sec practices that are actually being utilized. How to set up AWS secret manager so that your pods can fetch secrets like database secrets from AWS secret manager. I have shown proper branching strategy that will be utilized. How to set up the secretless authentication to uh AWS using GitHub YDC and securely access EKS cluster. How to deploy uh applications like uh stateful set based applications with persistent storage and how to set up the custom domain with ACM certificate ACM SSL certificate using ALB route 53 and ACM. Okay. Then monitoring the one those things that I explained you those things are there. I have also guided how you can purchase, how you can configure the SL certificates and custom domain. So these things are actually covered but uh again this is from completely scratch and in this uh in this project it's about 9 hours long. Okay. So as of now we are using this coupon uh we are have one coupon DevOps shack coupon which is I think valid for tomorrow. Okay. Let me see more questions. Guys, if you're taking too much time to type, you can just try to discount offer on courses. Bro, at least on Udemy, I have kept the already created a coupon 3. 99 9 hours course. But I can guarantee you that if you watch the whole video and watch the complete the course, you'll be having lot of knowledge uh with respect to like realtime DevOps. I'm how should I start? I'm working as cloud engineer. How does learn deops project meetings Saturday discussion? Uh Vishal my recommendation would be that key you uh for learning devops you know you pick up one project any project uh any project that you want to get started with you can pick it up and just build at least one project. If you build one project that will be more than enough guys one more thing let me show you like the project that I showed you how exactly it can be added to your resume screen. So basically this is one of document I created recently where I

have explained like how exactly you can add the project that I explained uh like UD this is the Udemy project. So how you can add the add it as a project in your resumeum. First point you can write design implemented end to end uh CI/CD deployment actions to automate build security scanning deployment to production on every mode. This part is the most important part in this line uh in this point because here you are mentioning this part key you're deploying to production. So interviewer will understand you have experience deploying to production environment. Then reduce the CI/CD time. I told you key this is something really important. If you're mentioning quantitative measures key like your work has what impact on the project. So here I already explained you like how exactly you can reduce the duration of the project duration of the pipeline. There are many factors. One of the factors is like parallel execution. Then parallelizing same thing we have written here but again added quantity to matrix. what dev secos practices we are using for what you are using then sonar cube I have separately kept it because it's it is very useful and it's actually going to remove all the bugs from your project then we have boost uh built and pushed container images to private uh registry highlighted here commit s tagging because tagging we are using automated that is going to be with respect to uh the this one commits then implemented secure deployment to Amazon EKS using GitHub YDC practices. This is something you know it it's a modern way of connecting to clusters. Okay. Also another point that can be added is with respect to monitoring and monitoring part I already explained what things you can monitor. So those things can also be added.