 The benefits of DevOps are well established and hopefully today you've learned a bit about the benefits of using a DevOps platform to do DevOps. But before we achieve any of those wonderful business outcomes, we need to actually get our software and our processes up and running. Now doing that on a DIY DevOps tool chain that you've built out of multiple solutions from multiple vendors can take you weeks. And even when you're done, it may or may not work the way that you want it to. Now, since GitLab is a DevOps platform with one single application for soup to nuts, everything you need to deliver value to your customer, as you might expect, it is considerably easier to get that going. But don't take my word for it. In our next talk, IBM's Seema Saharan will talk to us about GitLab's autodevops and how you can use that to get up and running right away. Let's check in and see what she has to say. Hello, everyone. In this talk, I will discuss about autodevops with GitLab CI. Before jumping to that, I would like to introduce myself. I am Seema Saharan, currently working as an associate systems engineer at IBM. And these are my handles for GitLab and Twitter. So the workflow of this session will be stages in GitLab pipeline. What is autodevops? How to enable it and integrate with a Kubernetes cluster. And finally, I will show you the demo, how you can trigger autodevops in your project. So first things first, the stages in a GitLab pipeline. So there are 12 stages. First is auto build, auto test, auto code quality, auto SAS that is static application security testing, auto dependency scanning, auto license management, auto container scanning, auto review apps, auto dash that is dynamic application security testing, auto deploy, auto browser performance testing. And finally, we have auto monitoring. So what exactly is autodevops? GitLab autodevops help to reduce the complexity of software delivery by setting up pipelines and integrations for you. So you don't have to worry about writing your pipelines or your YAML files. GitLab does it for you. You don't have to worry about that. So if you don't like writing your YAML files, so it will be a benefit for your project. So using autodevops, you can detect the language of your code. Automatically built test measure the code quality because usually we ignore code quality in our project. So and that is very, very important also. We can scan for potential vulnerabilities, security flows, licensing issues, monitor in real time and you can deploy your applications directly to the cluster. So how to enable autodevops? So for that you can go to settings and then CI CD and then you will find lots of options and the second option will be for autodevops. You can expand that section and you can enable it and you can also decide which environment you want to enable it for. So if you want that you directly deploy your changes, your code into production, you can select the first options. If you want to manually deploy it to production, then you can choose the third option. And second option is for like if you want to do incremental rollouts, you can do that also. So it depends on you and your project. So how do you want to do that? Next is how you can integrate a Kubernetes cluster. For that you need to go to infrastructure and Kubernetes cluster and then click on integrate with the cluster certificate. So there will be two options. You can integrate with either Amazon EKS or Google GKE. In this demo I have used Google GKE because it's much more easy to integrate it with GitLab. If you are already working on Amazon EKS then it's okay. I used Google GKE in this demo. So after you integrate with the cluster it will be like this. You will have a Kubernetes cluster displayed on your Kubernetes cluster section. And I know the name is EKS. Yeah, I forgot to name it as GKE but that's okay. So it will show you the nodes and your core CPUs and memory it has and everything about that. You can also click on that cluster to know more information and you can also integrate Prometheus and Elastic to know the metrics of your cluster. So after you do that, after you integrate your Kubernetes cluster and auto DevOps, you enable the auto DevOps, you will see in your project the main repository you will see that these two options will be there that Kubernetes is there. You have set up the cluster and you have also enabled auto DevOps. So now the demo part. So this is my project for this demo. And I didn't create any of this files. I just created the template that GitLab already provides and there are many templates to choose and they are already auto DevOps configured that they support auto DevOps. So I chose a project with Ruby. So now if you see that if I make any change in the code, any kind of, either it's small or big, any kind of change. So let's open up the web IDE that GitLab provides and I will change the read me file because you know it's easy. I don't want to change any code base. So I will just remove this line testing auto DevOps. I used it a few days back for testing purpose. So I just want to remove it and I will keep this line as it is. So I will commit this change and I will say that deleted this thing auto DevOps and read me file. Okay. And I want to create a new branch so that I will be able to create a new merge request and I will assign it to myself and create merge request. Okay. So you can see here that it's checking pipeline status and it will start running the pipeline before deploying it to the production. So it checks that whether this merge request is correct or not like whether it's ready to go to the production level or not and all these things. So it will take a while. So I will show you already merge request. Okay. So if you go to pipelines, you can see here that I ran this pipeline two days ago. And if I check this, all the stages have been passed. And if you check here that there are a few, there are actually many stages in this. First is build, of course. Second is test and test. There are multiple kinds of tests in this and next is review, that will check the security and next is performance and the last one is cleanup. So all these changes will be after it emerges. Okay. So all these kinds of changes will be there. And if you see here, the pipeline that is running right now, we can check the status what are the stages that are running in the pipeline. So there is build, test, review, test, performance and cleanup. So all these stages are there. And it takes a while to run all these pipelines and finally come to the cleanup stage. So that's okay. And also we can check what this particular stage is doing like. Okay. So it is building the Docker file. Since the project has not the Docker file, so it will just use the Docker file that Autodevops has. Okay. So all these pipelines were passed and some of them are failed, but that's okay. And the past one, we can check all the information here. It was this. So after, okay, if I revert it back, let's revert it back. Okay. So we can check here after this pipeline finishes and we do the merge, all the pipelines will pass and then we will do the merge. Because it's ready to be in production. So since I have enabled the Autodevops to be directly deployed to the production, so it will just run the pipeline and deploy it to production. So that we can see those changes in our project. Okay. So it will be there. So we can also check what this pipeline has like some information. We have like browser performance test metrics for our same three were improved. So that's pretty good. And we found one high. We got some vulnerabilities and one is really high. So we can check that and check. We can review the full report and click on that. We can also check what kind of security issues are there and which file is causing that. So we can also dismiss this or create a new issue and correct that and everything. So GitLab provides all of these things because usually we can't find them and GitLab does it for us. And also we got new, no new licenses. So it's checked and pipeline is passed two days ago. That was old pipeline. Okay. So that's pretty, it's still running, but you got the gist of how autodevops work. And there are so many things to explore in autodevops. Like you can see the metrics of your cluster, how it's using the CPU and all the things. Okay. And that is not it. You can also customize your YAML files that if the same pipeline is running again and again, so you can use cache for your pipeline so that it will not take much time. And one thing I forgot, if you see that we don't have any YAML file like .gitlab.ci.yaml file, we don't have that file in our project. So that's autodevops. It won't run the pipelines on our project, but on the GitLab side. Okay. So that's basically the autodevops and you can do multiple things. Okay. So if we go to the environments, you can check that we have one environment that is production environment and you can also create new environment. So just ignore that. Okay. So we have one instance available for production environment and you can check all the things that what it is, what it has. Okay. And I have also told multiple things about how you can customize your environment. If you don't want to deploy directly to production, then you can just go to settings and then CICD and then you can configure that. And you can also create multiple Kubernetes clusters and multiple environments. So it totally depends on your project, how big it is, how many environments you want. So you can always customize that and you can refer the GitLab documentation. It's pretty good. It explains everything and you can try that. Okay. So that was it for this session. I hope you enjoyed it. I hope you have gained something and thank you so much.