Day-18 | What is CICD ? | Introduction to CICD | How CICD works ? | #devops #abhishekveeramalla

Summary

In this video, Abhishek Veeramalla delves into the core concepts of Continuous Integration and Continuous Delivery (CI/CD) as part of a comprehensive DevOps course. He emphasizes the necessity of CI/CD for modern software development, enabling faster and more reliable application delivery through automation. Abhishek breaks down essential steps such as unit testing, static code analysis, code quality testing, and deployment, highlighting how these steps can be automated using tools like Jenkins and GitHub Actions, especially for massive projects like Kubernetes. He also touches on the limitations of traditional CI/CD tools and introduces emerging solutions to enhance efficiency and scalability.

Highlights

• Abhishek shares insights into the basics of CI/CD - crucial parts of modern DevOps practices. 🌐
• Introduces CI/CD steps - from integration testing to production deployment and beyond. 🛠️
• Discusses the importance of automating processes to achieve faster application delivery. ⏱️
• Explains Jenkins' role as an orchestrator for executing CI/CD pipelines. 🤖
• Talks about the move from legacy to more scalable solutions like GitHub Actions for CI/CD. 📈

Key Takeaways

• CI/CD stands for Continuous Integration and Continuous Delivery, essential for streamlined software deployment. 🚀
• Automating testing, analysis, and delivery via tools like Jenkins and GitHub Actions can save time and resources. 🔧
• Legacy CI/CD tools, while foundational, can be replaced or supplemented by modern, more scalable options. 💡
• The CI/CD process can drastically reduce the time from code commit to production deployment. 📉
• Understanding CI/CD pipelines can advance one's career in DevOps and software engineering. 💼

Overview

In this engaging session, Abhishek Veeramalla takes viewers through the essentials of CI/CD, an indispensable component of contemporary DevOps strategies. With clarity and expertise, he outlines how Continuous Integration and Continuous Delivery come together to enhance software release cycles.

Abhishek highlights the step-by-step automation process that CI/CD brings to software testing and deployment. By integrating tasks such as unit testing, static code analysis, and more frequent deployments, teams can accelerate their release cadence significantly. This not only increases efficiency but also boosts software reliability.

As traditional CI/CD tools like Jenkins are explored, Abhishek also paves the way towards understanding newer, scalable tools like GitHub Actions. He underscores the importance of adaptability in DevOps, urging viewers to embrace evolving platforms to streamline their development pipelines, ensuring robust, timely deliveries.

Chapters

• 00:00 - 00:30: Introduction to CI/CD In this introductory chapter on CI/CD, Abhishek, the host, welcomes viewers back to his devops course, which is now on day 18. The chapter highlights the significance and popularity of CI/CD among the audience, evidenced by numerous requests for detailed content on the topic since the beginning of the course. Abhishek acknowledges having previously covered CI/CD in his videos and sets the stage for diving deeper into it in this segment.
• 00:30 - 01:00: Basic and Advanced CI/CD Setups This chapter provides an overview of both basic and advanced Continuous Integration/Continuous Deployment (CI/CD) setups. It is part of a comprehensive 45-day DevOps course aimed at introducing learners to CI/CD concepts, tools involved, and practical projects. The chapter starts by explaining a simple CI/CD framework and progresses to more sophisticated setups, allowing learners to grasp the broad scope and application of CI/CD in the software development lifecycle. Practical examples and projects are used to deepen understanding and facilitate hands-on learning.
• 01:00 - 01:30: Modern vs Legacy CI/CD The chapter discusses the evolution from legacy CI/CD setups used five years ago to modern CI/CD practices. It highlights the limitations of traditional CI/CD systems, emphasizing their lack of scalability. The chapter also introduces modern applications and tools like Kubernetes, and platforms like Amazon and Flipkart, which have adopted new CI/CD methodologies to enhance scalability. The discussion aims to compare these older methods with the advanced solutions being used today to handle continuous integration and continuous deployment efficiently.
• 01:30 - 02:00: Introduction to CI/CD Concepts Continuous Integration and Continuous Delivery (CI/CD) explained simply.
• 02:00 - 02:30: Practical Example of CI/CD This chapter focuses on a practical example of Continuous Integration/Continuous Deployment (CI/CD). It begins with a textbook definition explaining that continuous delivery is the process of deploying an application to a specific platform for customers. To provide clarity, the chapter uses a real-world example involving an application developer. The discussion includes integrating a set of tools and processes to be followed before an application is delivered to the customer, illustrating the practical application of CI/CD principles.
• 02:30 - 03:00: Steps in CI/CD Process This chapter discusses the process of delivering software applications from the developer's personal environment to a customer located anywhere in the world. It highlights the importance of this process for organizations of all sizes, including startups, multinational corporations, and even major technology companies. This delivery process is a crucial part of the Continuous Integration and Continuous Delivery (CI/CD) practices, ensuring that applications can be reliably and efficiently deployed to meet global customer needs.
• 03:00 - 03:30: Unit Testing The chapter on 'Unit Testing' emphasizes the importance of testing applications to ensure their reliability and security. It highlights the necessity of scanning for security vulnerabilities and generating reports to confirm that the application is functioning correctly. The ultimate goal is to deliver the application to the customer in an efficient and reliable manner, following a series of steps to ensure it is ready for deployment.
• 03:30 - 04:00: Static Code Analysis The chapter discusses the variable nature of static code analysis steps, which can change depending on the type of application being developed, such as mobile or web applications. The steps may vary based on the security requirements or the nature of the project, such as working on a government project. However, despite these variations, there should always be a standardized set of guidelines that a company follows to deliver applications to customers.
• 04:00 - 04:30: Code Quality and Vulnerability Testing The chapter titled 'Code Quality and Vulnerability Testing' discusses the importance of automating processes in Continuous Integration and Continuous Deployment (CI/CD). The speaker explains that manually performing tasks like unit testing, functional testing, or regression testing after every code commit would significantly delay the delivery of applications to customers. In contrast, automating these processes as part of a CI/CD pipeline allows for rapid and efficient software delivery. Emphasizing modern practices, the chapter underscores the significance of automation in maintaining code quality and addressing vulnerabilities swiftly.
• 04:30 - 05:00: Automation Testing The chapter titled 'Automation Testing' discusses the importance of automating various steps in application development. It highlights that while the specific steps might vary between organizations and products, certain steps such as unit testing and static code analysis are standard practices. The chapter also promises further explanation on each of these steps.
• 05:00 - 05:30: Reporting and Deployment In the 'Reporting and Deployment' chapter, the focus is on the importance of conducting thorough testing and analysis before delivering a software application. Key practices include static code analysis and code quality testing to identify potential vulnerabilities. Ensuring high application security is emphasized as crucial to maintaining customer trust. Additionally, automation testing, such as end-to-end testing, is highlighted as a vital step in the deployment process to ensure the functionality and reliability of the application.
• 05:30 - 06:00: CI/CD Pipeline Explanation The chapter explains the CI/CD pipeline process in software development. Initially, it outlines the necessity of having a reporting mechanism for applications to ensure everything is functioning correctly. This includes verification of all checks. Deployment is highlighted as a critical step, emphasizing that it is mandatory for client access. The chapter underscores the importance of following standard steps in every organization to ensure the delivery of a correct application to customers. The purpose is to give an understanding of each standard step involved in the process.
• 06:00 - 06:30: Jenkins as a CI/CD Orchestrator This chapter introduces Jenkins as a Continuous Integration and Continuous Deployment (CI/CD) orchestrator. The conversation begins with the concept of unit testing, emphasizing its role in automation using Jenkins. An example of a calculator application is used to illustrate how unit testing works, particularly focusing on writing and automating tests for a simple addition function in Python. The chapter further explores the integration of Jenkins to automate the testing and deployment process.
• 06:30 - 07:00: Pipeline Automation The chapter titled 'Pipeline Automation' discusses the concept of unit testing in software development. It explains that unit testing involves testing specific blocks or functionalities of code to ensure they work correctly. The chapter highlights the importance of automation in this process, as developers make frequent changes that would be inefficient to test manually each time.
• 07:00 - 07:30: Environment Staging and Production The chapter titled 'Environment Staging and Production' discusses the process of moving from one development stage to another. It highlights the importance of static code analysis in this process. A basic example is provided, such as creating a calculator functionality where excessive memory allocation can occur by declaring too many variables. Static code analysis is used to identify and mitigate such issues to prevent memory wastage.
• 07:30 - 08:00: Scalability Issues with Jenkins The chapter discusses issues related to scalability when using Jenkins, focusing on the importance of static code analysis. It emphasizes ensuring the application is well-formatted, properly indented, and free of unnecessary variables. These aspects are crucial for code quality and can help identify issues that might be missed by peer reviewers or code reviewers. The chapter highlights the role of code quality or vulnerability testing in maintaining scalable and robust applications.
• 08:00 - 08:30: Modern CI/CD Tools - Kubernetes Example The chapter discusses the importance of quality testing and automation in CI/CD processes, particularly in the context of upgrading software like Android. It emphasizes how identifying issues such as security vulnerabilities before releasing updates to customers is crucial to ensuring a good user experience.
• 08:30 - 09:00: GitHub Actions Explanation The chapter titled 'GitHub Actions Explanation' focuses on the concept of automation testing. It begins with a discussion on unit testing, where individual functions or features are tested for correctness. The example provided is verifying a function to see if 'a + b equals c' by passing parameters, such as 2 and 3, and expecting the result to be 5. Following this, the chapter moves on to functional testing, which ensures that new changes or additional functionalities, like an addition function, do not adversely affect other operations, such as subtraction.
• 09:00 - 09:30: CI/CD Alternatives The chapter discusses the importance of verifying applications comprehensively. It emphasizes that testing should not be limited to individual changes but should cover the application end-to-end through functional or end-to-end testing. Additionally, generating and maintaining reports is highlighted as critical, particularly for unit test coverage, code quality, and tracking test pass rates. Organizations rely on these reports for insights and decision-making regarding their software's quality and performance.
• 09:30 - 10:00: Comparison of CI/CD Tools The chapter "Comparison of CI/CD Tools" discusses the various steps involved in deploying an application, highlighting the importance of automation in the deployment stage. It notes that without proper deployment, the application cannot be accessed by customers. The chapter emphasizes that manual execution of these steps is time-consuming, thereby underscoring the efficiency that CI/CD tools bring to the deployment process.
• 10:00 - 10:30: Conclusion and Upcoming Video Preview This chapter explains the process of delivering an application to the customer, highlighting the iterative nature of software development. It describes how developers break down functionalities into smaller tasks, create Jira stories for each feature, and submit their work incrementally to a Git repository.

Day-18 | What is CICD ? | Introduction to CICD | How CICD works ? | #devops #abhishekveeramalla Transcription

• 00:00 - 00:30 hello everyone my name is Abhishek and welcome back to my channel so today we are at day 18 of our complete devops course and in this video we'll be talking about CI CD yeah so this is one of the videos that is most asked from the day we are doing day Zero everybody has been asking about cicd like I get a lot of comment requests uh asking okay can you please do a video on cacd also I have done a couple of videos on cicd if you watch or if you take a look at my
• 00:30 - 01:00 channel so there is a basic CI CD setup that I've explained on also I have explained about a complicated or Advanced cicd setup but it's fine I mean as part of this 45 days of devops course we should also talk about cicd where you know we will try to understand what a cicd will introduce ourselves to the world of cicd what are the different tools that are uh you know part of this uh cicd and we'll also take a look at couple of projects okay so when I'm talking about the projects I'll show you what is the basic
• 01:00 - 01:30 CI CD setup that people were using five years ago or you know what is a legacy CI CD setup and how this Modern Day applications like for example we have modern applications like kubernetes kubernetes is a project right Amazon or Flipkart so how these people are doing cicd okay because the Legacy uh cicd setup is not scalable so there has to be a modern day solution uh and we will talk about the modern day solutions for the cicd as well okay now before going there uh what we should
• 01:30 - 02:00 understand is what is cicd right because there are many people on our Channel who might not understand what is cicd so for them if I just try to explain cicd very quickly CI CD is basically two steps right one is continuous integration and the second thing is continuous delivery okay so there are two parts to cicd so continuous integration is a process
• 02:00 - 02:30 where you integrate a set of tools or you know you integrate set of processes that you follow before delivering your application to your customer and continuous delivery is a process where you deploy your application or you know you deliver your application on a specific platform to your customer for example okay so this is a textbook definition now let's try to understand this using a practical or real time example you have your application let's say you are a application developer and you have
• 02:30 - 03:00 developed your application on your personal laptop and your customer is sitting somewhere in the USA or Europe or some other part of the world and you are sitting in a different part of the world let's say okay so how your application is delivered from your personal laptop to the customer who is sitting in a different part of world so this process okay every organization goes through this right whether it's a startup whether it's MNC or whether it is man companies everyone has customers over the globe and your application has
• 03:00 - 03:30 to be delivered to your customer in a prompt or you know in a efficient and reliable way that is your application has to be tested right your application has to be scanned for any security vulnerabilities your application has to be like you know there has to be reports which suggest that okay everything is perfect with respect to your application finally you deploy your application somewhere which your customer will be able to access so these are certain steps like for example these are the
• 03:30 - 04:00 steps that I explained you and from customer to customer or from a product to product these steps might vary let's say you are a mobile application these steps might increase or decrease okay let's say you are a web-based application or your application is very very secure you are dealing with some government project or something so these steps might increase or decrease depending upon your application but in general there has to be a certain set of standards your company follows to deliver the application to the customer
• 04:00 - 04:30 so cicd is a process where you automate all of these things right if you have to do all of these things manually let's say you have to unit test your application every time you have to functionally test your application or perform regression testing on your application every time even a single code commit that is made by developer if you do all of these things by the time your application reaches the customer it would it would take months of time but in the modern day or you know these days you're you are talking about delivering
• 04:30 - 05:00 your application in weeks of time or you know in days of time so to achieve that you have to have all of these steps automated right what are the steps so some of the steps okay this this does not have to be uh common across uh every organization or this does not have to be common across every product but some of the standard steps that you follow are unit testing your application right so you always have to unit test your application you have to perform static code analysis don't worry I'll explain about each and everything
• 05:00 - 05:30 you have to do some static code analysis you have to do some uh like you know code quality or vulnerability testing because for a customer you cannot deliver application with some security bugs and then you have some kind of like you know automation testing like end-to-end testing of your
• 05:30 - 06:00 application then you might have some kind of reporting for your application right where you store all of your reports uh say that everything is working fine all of your checks are verified and finally you might want to deploy your application this is mandatory right without deploying your application your client will not be able to access your application so these are some standard steps that every organization has to follow without these steps you are not sure that you are delivering a right application to your customer okay so now let's try to understand what are these steps each and
• 06:00 - 06:30 everything and then let us see how cicd will automate all of these things okay so firstly what is unit testing so unit testing is nothing but let's say you are writing a calculator functionality or you are writing a calculator application where you are writing addition functionality okay so whenever you are writing addition functionality let's say you are writing this in Python what you will do is if you are writing code for a plus b is equals to C so you will pass some arguments like you know in your testing you will say pass
• 06:30 - 07:00 two and three and verify that the output is 5 okay so this is nothing but unit testing your code okay you are testing your code in that specific block or you are testing the code with respect to that specific functionality this is called as unit testing okay every application developer has to do this and you know this process cannot be manual because every time uh the application developer is making changes to it uh you know hundreds of times they cannot run this manually before delivering to the customer or before submitting to the
• 07:00 - 07:30 uh any any staging or promoting from one stage to another stage then you have static code analysis so static code analysis for let me give a basic example let's say that uh same example I'm writing a calculator functionality and I have declared 20 variables and I will just use two variables okay so the problem is there is a lot of memory allocation that is happening here and you are wasting a lot of memory right so to avoid this what we usually do is that we do some static code analysis to verify that you know you are
• 07:30 - 08:00 syntactically right you have well formatted your application okay in some programming languages uh formatting or the indentation is also very important right so you have to verify all of these things like your application is well formatted your application has all the indentation right you did not declare any unnecessary variables or there are a lot of other things so this kind of things are called as static code analysis sometimes your code reviewer or your peer reviewer might not catch all of these things then you have code quality or vulnerability testing that is
• 08:00 - 08:30 let's say uh you got a new version of uh Android yesterday and you have upgraded the new version of Android and today you came to know that there is a security vulnerability there can be a hacker who can you know attack your mobile then that's a very bad customer experience right or it's a very bad user experience so before we deliver to the customers or before we promote uh the environment the application from one stage to another stage what we usually do is that we do the code quality testing and then there is automation automation
• 08:30 - 09:00 uh by which I mean to say automation testing that is in the first step we did unit testing that is we tested the feature or we tested functional functionality of that specific function uh to a plus b is equals to C what we do is we pass 2 and 3 and see that 2 plus 3 is equals to 5 this is unit testing whereas you have functional testing with functional testing you will verify that you know the change that you have done or the addition functionality that you have written does not impact subtraction
• 09:00 - 09:30 multiplication or division functionality okay so you verify your application in a end-to-end manner okay not just your function change that you have done but end to end of your application you verify using the functional testing or end-to-end testing then you have some reports these reports are very essential for any organization like you know tomorrow if somebody asks you what is your unit test coverage how many unit tests pass how many end to end has passed in this specific thing or what is the code quality thing is it fine or not so you need to have reports every organ nation has this they store report
• 09:30 - 10:00 somewhere and then finally you have the deployment stage so deployment stage is for deploying your application onto a platform where your customer can access this application so without that no matter what you are doing your application is not available to the customer so these are some of the steps that every organization follows and to do all of these texts manually let's say you are doing all of them manually you will take a lot of time to deliver your application to customers right because it's always not like today you make a
• 10:00 - 10:30 code change and you deliver to your you deliver your application to the customer no right so what usually happens is whenever you are writing an application or whenever you are writing a feature you will not write everything in one step what you do is you break them into chunks okay so you create some jira stories for each of the feature or each of the functionality and you keep submitting them to your git Repository right so you store each and everything in your gate repository and every time
• 10:30 - 11:00 you are confident about a change let's say again if you go back to the example let's say I'm writing addition functionality I'll write first version of my addition functionality tomorrow I'll write version 2 of my Edition functionality day after tomorrow I'll read version three okay finally eventually maybe on version 10 or version 15 I might be satisfied about my addition functionality and I'll say okay this version 15 has to go to the customer right so before that whenever you are writing this version one version two version three version four all of them
• 11:00 - 11:30 have to be stored in some place in general this is called as a VCS version control system or you know it can be any I mean VCS is a name and the different tools for VCS are nothing but your GitHub or your bitbucket or your gitlab some of these tools right so your CI CD is or your CI CD gets executed when you push your changes to one of these tools
• 11:30 - 12:00 okay so whenever this application developer is confident about version one what he does is he'll push this version one onto the VCS or version control system from there your cicd process will take care right instead of manually executing all of these things what will happen is once you submit once you are confident about your local changes as a developer once you submit your changes to a Version Control System then your CI CD pipeline will actually take place so what is the cicd
• 12:00 - 12:30 pipeline what are the tools so let's start with the Legacy tool and see how it will automate the process Okay so if we start from where we stopped okay so application developer again so he is confident about the version one of the addition functionality that he has written what he'll do is he'll submit that into a git Repository let's say it happens to be GitHub in our case okay so he puts the changes to GitHub
• 12:30 - 13:00 now from here all the things that we discussed should take place that are unit testing static code analysis automation testing blah blah blah so what we will do is we will you know deploy a cicd tool for example we will deploy Jenkins in our organization and what we will tell Jenkins is always watch for this GitHub repository and whenever there is a pull request or you know whenever there is a new commit that is made onto
• 13:00 - 13:30 this git repository on a specific branch on a specific report okay just tell me that you know there is a change that is made and what I will do is I will run a set of actions okay so what Jenkins will tell is notify me whenever developer is submitting any change onto a specific repo onto a specific branch and as part of the automation Jenkins will run all of the steps that I have told you okay the unit
• 13:30 - 14:00 testing static code analysis and all of them so how will Jenkins do that okay okay I explained you that Jenkins will do it so what Jenkins will do is Jenkins will act as a orchestrator or it will act as a pipe or a tunnel okay now what Jenkins will do is that as set off as part of this pipeline tunnel or you know you can consider anything Jenkins will automate a lot of tools in it or it will orchestrate a lot of tools in it so these tools are for example if we talk about unit testing and building the application what you can do is you can
• 14:00 - 14:30 run them as part of if it is a Java application let's take Java application so you can integrate your building of application in Maven and running unit as using some uh you know junit or Jack Coco for code coverage or code second okay so let's say you integrate Maven which will take care of building your application and running your unit test and then Jenkins can also integrate something like sonar for your code quality code testing then Jenkins can integrate Alm
• 14:30 - 15:00 you know or any other reporting tool for reportings so who will do this devops engineer will install or you know configure all of these tools within Jenkins so that they uh you know they get run whenever your code is committed to the GitHub repository we will also see that in tomorrow's video don't worry about it so Jenkins pipeline is not at all difficult to write we'll start with Jenkins Pipeline and then we will move to Advanced tools that we have been talking about okay and then for example
• 15:00 - 15:30 after this happens to be deployment then you can integrate k8s or any Docker platform or you know you can also integrate any ec2 instance or cloud-based VMS so this all things can be automated within your Jenkins pipeline so that's why Jenkins is called as a orchestrator okay what do we call Jenkins as Jenkins is a orchestrator which will facilitate all of these tools okay or it will integrate all of these tools within it by using Jenkins pipeline okay so that's why Jenkins
• 15:30 - 16:00 pipelines are very important whenever you are watching for any job description okay or you are looking for any uh you know openings in devops I'm pretty sure you must have heard this world called pipelines or you must have at least uh you know saw this term called as cicd why is it very important because of all the reasons that we just talked about without cicd your applications will be delivered to customer months after months you develop your application right so who is solving the problem or who is ensuring your application is
• 16:00 - 16:30 delivered within minutes or within hours that is the CI CD process now we talked about Jenkins so in Jenkins terminology we call them as Pipelines okay so Jenkins pipeline is something that takes care of automating all of these tools and executing the actions that these tools do okay once you integrate Maven your thing is to I mean the pipeline should also integrate Maven and it should also execute Maven similarly sonar Alm k8s or any set of tools that we talked about
• 16:30 - 17:00 so with this we'll improve the efficiency of your application it will also I mean so this is step one in step two what you can also do is that like you know uh whenever you are again you are a app developer you are committing these changes onto a git Repository okay so your Jenkins pipeline here can also you know promote your application to different stages firstly your application uh Jenkins can promote your applications to Dev environments then
• 17:00 - 17:30 whenever it is confident what it can do is it can promote the application to staging environment and finally it can promote to production what is this process okay so this is a very important thing uh stay with me stay focused I'll explain you in detail so usually what happens is organization divide their environments to multiple things like you know there is a production environment which is very similar to the I mean it is very similar or it is the exact environment that
• 17:30 - 18:00 customers are using your applications okay so some in some cases you will use a pre-production environment or in some cases you will directly use a production environment so in terms of production environment this is the exact uh environment where your customer is using your application okay let's say here your customer is using application so even though you perform all of the step steps that I mentioned in the previous slide there is a difference between the environmental environment right so what happens is usually the production environment will have lot of servers are
• 18:00 - 18:30 it it replicates the exact setup where you are deploying your application to your customer in staging you might have less amount of CPU or less amount of RAM and and you want to deploy your application before every time you deploy your application to production and Dev is like -1 for your staging so Jenkins can take care of deploying your application to multiple stages okay so the reason why your application has to be deployed initially to Dev platform is your queue Engineers would firstly want
• 18:30 - 19:00 might want to or you know your automation might want to execute uh initially on a simple environment like you know a very simple easy to instance and once uh things are looking good your Jenkins can automatically promote using some manual approval or automatic approval once everything are looking good on the dev platform you can do an automatic approval and using this automatic approval Now application will be moved from Dev to staging environment so in the staging environment like you know instead of a simple ec2 instance you might have a cluster here
• 19:00 - 19:30 okay maybe using Auto scaling you created two easy new instances or maybe you are using a kubernetes platform where you have uh here you just might have one master and one node here you might have uh three Masters and five E nodes or five worker nodes and in the production you might have some three Masters and some 30 worker nodes okay so every time before you reproduce this environment on production or before you deploy your application on production you might want to test it on a single node kubernetes cluster which is your Dev environment then you might want to
• 19:30 - 20:00 go staging which is your three master and fine node architecture and then you might want to actually deploy to your customer so why you cannot have production like environments uh even in staging is because this is a very costly setup right so your customer you might give you a very cost you might give a very rich and robust setup but every time you want to test it with your local testing team or your local QA team you might not have that rich setup so that's why you deploy your applications onto Dev and staging environments right are things clear till now so if you have
• 20:00 - 20:30 any questions till now or till this point of time definitely post that in the comment section so that I can understand okay at this time stamp you did not understand something so please also put the timestamp so that I can take this as a constructive feedback and improve myself next time okay so now once you understood all of these things okay so this is of Jenkins which is a legacy tool the reason why I'm stressing it as a legacy tool I
• 20:30 - 21:00 don't mean to say that uh Jenkins has not used these days or I don't want to like you know uh defame Jenkins but the reason is that Jenkins has been a tool that is like you know people started with Hudson like I mentioned you so this was a tool that was used like everybody might have started with Hudson or Jenkins if they are a developer devops Engineers from seven to eight years back and then people eventually moved to uh Jenkins okay and uh you know everybody uh start dealing with on-premises first and then they move to
• 21:00 - 21:30 Cloud platform but these days everything is micro Services right if you look at uh for example Twitter or if you look at uh some applications like uh Flipkart or Amazon so they are basically some thousands of micro Services right there are basically some thousands of services now to deploy these thousands of services okay Jenkins is a platform tomorrow you will understand whenever we
• 21:30 - 22:00 are deploying Jenkins so Jenkins is nothing but it's a binary okay and what you will do is basically you install Jenkins on one host probably your laptop or your ec2 instance and then you keep adding machines to it because there are hundreds of developers in your organization and one Jenkins node cannot take all the load so what usually you do is you deploy your Jenkins Master on one ec2 instance and then you keep connecting multiple ec2 instance to it and then you will say let's say there are 100 developers or then there are 10
• 22:00 - 22:30 teams you say that okay for team one uh every job that is running or every change that is made to your GitHub repository run the pipeline on node one for team two run it on node two for team three run it on node three four five Etc okay now the problem here is that this has to scale up right so if there are 10 teams in your organization you might create some 10 Jenkins machines okay and again for each uh development team inside that specific team you might
• 22:30 - 23:00 want to uh set up some additional VMS for running the nodes on specific or running pipelines on specific nodes so this setups become very humongous right because every time you scale up this Jenkins instances you know you have to create lot of lot of computer okay so compute is basically very costly even in during our virtual missions class I explained you that compute is basically your RAM right your CPU and let's say your Hardware okay so this
• 23:00 - 23:30 is your compute now when you keep adding compute to your Jenkins instances the setup becomes not only very costly but the maintenance also becomes very huge okay so instead you should actually look for some setups which can scale up and scaled on automatically so people might ask one question here okay I can integrate my Jenkins with auto scaling groups and I can scale up
• 23:30 - 24:00 and scale down automatically but see we are talking about some real time things right let's say you have to scale your Jenkins to complete zero you I don't even want my Jenkins masternode to exist that is not possible because there are times let's say uh during your weekends or uh during uh some odd times there is no I mean there is some zero code changes that are made and zero pipelines that have to be executed okay in case of thousands of micro Services where you
• 24:00 - 24:30 have some 20 to 30 Jenkins uh instances and uh 20 to 30 Jenkins setups okay we are talking about 20 to 30 Jenkins masternodes and again three to four worker nodes so if you are not configuring them well so at any given point of time you have some hundreds of virtual machines which are created but not used but my condition or my requirement is that I have to have zero servers when I'm not using any or when I'm not making any code changes so in
• 24:30 - 25:00 such cases Jenkins is not a tool that you should recommend okay so let us see how this Modern Day applications okay let us take a look at one example because these days most of this you know there are some applications that are highly scalable and they are open source so let us take a look at one very popular open source application that is kubernetes and let us see how kubernetes is managing these things because you know kubernetes has some thousands of developers okay they are in
• 25:00 - 25:30 different parts of globe and they usually communicate using GitHub right so let us see how kubernetes is handling these things whenever a developer in India making a code change to GitHub repository of kubernetes how kubernetes is dealing with the code change and how it is ensuring that it is not wasting the VMS that I just explained okay so let me stop sharing this one and start sharing a new screen
• 25:30 - 26:00 foreign and then let me share my browser here so this will be really interesting and uh I would request many people who don't know uh the GitHub actions or gitlab pipelines to just like you know if you have any questions don't worry I'll definitely explain these things in tomorrow's class where you will be definitely able to understand the setup
• 26:00 - 26:30 so I have increased the font and see here this is the kubernetes GitHub page similarly you will have uh GitHub repositories or gitlab repositories in your organization as well where developers will commit the code changes to this version control system so if you see here kubernetes has 3347 contributors that are developers now anytime any developer might do a code change but at this point of time no developer is making code change because I am not seeing any new comments to
• 26:30 - 27:00 master Branch or I am not seeing any new pull requests so by the time I logged in there are 761 and even now there are only 761. so let us see how kubernetes is handling Whenever there is a pull request or whenever there is a commit that is made so if you go to the pull request okay so the last pull request was four hours ago so for the four hours there is no code change that is made or there is no pull request that is made so the expectation or the ideal scenario should be for this four hours okay from
• 27:00 - 27:30 past four hours there should be zero compute instances kubernetes project must be wasting okay if not you are losing a lot of money for your organization you are wasting a lot of money for your organization so if you see this pull request what usually happens is they have configured it using GitHub actions okay so here what they are doing is they are running the entire thing using GitHub actions so GitHub actions is another way of doing CI CD just like Jenkins and what happens here
• 27:30 - 28:00 is whenever a code chain is made it will spin up a kubernetes pod or you know a Docker container for you and everything gets executed on the docker container and if you are not using it then you know the server or the worker which is used to run these Docker containers will be used by some other uh projects like you know you do a shared resources so in the concept of shared resources the advantage is that so kubernetes project there are uh like
• 28:00 - 28:30 you know if you go to the kubernetes organization here there are some 77 repositories or you know if you are using GitHub actions uh and if you are using runner from GitHub itself or you're if you are using Runners from Microsoft Runners are nothing but worker nodes from Microsoft so what Microsoft will do is that it will create containers for you or kubernetes pods for you on the Microsoft servers itself or the Azure servers itself so you don't even know where the servers are getting created and if it is
• 28:30 - 29:00 a public project or open source project you will get it for free so let's say you don't want to use Microsoft okay and your code is secure what you can do is that let's say for this 77 repositories you can create one common server okay you can host the server on Azure you can host the server on AWS or it can be kubernetes cluster anywhere in the world and what you can say is that whenever a developer is making commit on any of the 77 repositories okay so what you will do is you can create a kubernetes pod on this kubernetes cluster and once the
• 29:00 - 29:30 execution is done all of these steps are done just delete the part so that I'll be free one more time okay then any other project can use that kubernetes so what you have done here is instead of wasting resources for each and every project instead of creating Jenkins instances for each and every project you can create one common GitHub actions which can be used across multiple people in your organization or multiple projects in your organization and you can basically you know save your
• 29:30 - 30:00 resources save your computer and if nobody is using it there is no wastage because the server size is shared across everyone so literally you are using zero compute instances when there is no code change so this is about your modern day CI CD setup I'll also explain you in T10 whenever we are going to talk about future projects in tomorrow slash and Day After Tomorrow class and one more Advantage is that you know your Solutions are extremely scalable that is uh today if you are using a Jenkins
• 30:00 - 30:30 instance every time you have to add one more server what you will usually do is you keep adding one more worker node or you just you know make any additional worker node and attach them to your existing Jenkins setup whereas in terms of kubernetes you all know that easily you can increase one more node and you know you can scale it up to 100 000 or whatever you would like to and if it is a manage kubernetes cluster on eks I mean or Amazon or something you
• 30:30 - 31:00 can directly add nodes scale up these nodes or scaled on these nodes right make sense so this is uh some examples about cicd today basically uh today we did not discuss uh practically about anything I just wanted to show you one real-time project so most of this open source projects use GitHub actions okay so one more tool that I wanted to introduce you many people uh definitely you know whenever you watch the Youtube videos or whenever you start uh working with a cicd for the first time you will
• 31:00 - 31:30 definitely start with Jenkins but you should also understand that there are very good Alternatives so there are projects on GitHub there are projects on gitlab there are projects on You Know Travis CI there are products on Circle CI so these are all Alternatives and these are all emerging cicd Solutions so even if you don't have good knowledge of how to implement them one should definitely understand the Alternatives and you know eventually every everyone might move towards it like if you ask me uh I like GitHub actions over Jenkins because of
• 31:30 - 32:00 the reasons that I just explained you right for example if I have to compare let's say you will ask me to compare uh definitely in future I'll do a video where I'll compare uh Jenkins with cicd but there are many advantages with actions like they are event driven um even Jenkins is even driven but you can only configure pull request action using some web hooks or you know whatever web hooks that githubs are supporting but if there is no web hook configuration for Jenkins by default it
• 32:00 - 32:30 is not event driven whereas GitHub actions are default event driven continuous integration and continuous Delivery Solutions and you know you can also what you can do with uh GitHub access is you can integrate your pipelines uh from one project to the other projects as well so there are many advantages that GitHub actions provides you and uh in tomorrow's class and day after tomorrow's class we will try to experiment them on one project using Jenkins as well as GitHub actions so
• 32:30 - 33:00 people also asking about are also asking about gitlab pipelines or gitlab cicd so don't worry about it like you know we cannot cover all of them but if you know GitHub actions gitlab cicd is very similar even if you to take an example on gitlab you can search for search for that on stack Overflow or something you'll find them exactly similar only the only thing is that there are syntactical differences and symmetrical differences that's the only thing okay so I hope you like the video
• 33:00 - 33:30 today and uh if you are waiting for tomorrow's video just post that in the comment section uh share your feedback for me on Twitter on today's video and I'll be waiting for you in tomorrow's video I hope all of you joined tomorrow's video and perform a practical scenario thank you so much I'll see in the next video take care everyone bye