 Okay. Alright, so we are going to be practicing our session for AWS re-invent. We're on demo 60 or something on the partner stage, Pill with Theatre, tomorrow, which is Wednesday at 12.10 p.m. And this very janky recording is going to go up on YouTube because we publish all our videos. So here goes nothing. Oh, just FYI, Dan is going to play Sid's part, Sid is our CEO. Cool. So let's get started. Alright. Reinventing your pipeline with GitLab, Kubernetes, and Amazon EKS. Hi, I'm Sid, CEO of GitLab. And I'm Priyanka, Director of Cloud Native Alliances at GitLab. At GitLab, we believe that everyone can contribute. Making this possible is our mission. It's what drives not just our product vision, but also how we run our companies. GitLab is used by over 100,000 organizations across the DevOps life cycle. It's the first single application for planning, software development, security, and operation. Yep. And a single application is the biggest reason folks resonate with GitLab. This is because there is a tool chain crisis happening in today's ecosystem. It delays organizations from getting the advantages that DevOps can bring them. That's right. And there's a lot of tools out there. And the challenge that people have is keeping them all integrated. There's tools that have lots of plug-ins to make the functionality that you need work. And the integration work and maintenance challenges are large in keeping those all running together. Plus, with multiple tools, we have the problem of context switching with your developers and your operations and your security people need to switch between tools just to get information about what they've just run and what status they're at. If you can switch, it's time-lapse, so we ideally want to not have the switching happen. Plus, this also means that across the different tools, not everyone has the same visibility of all of the data, so it's harder to work and close everything down. As a matter of fact, we originally thought that it didn't make sense to have everything as one. We didn't originally get that idea. And then, Dimitri, our founder, when we had GitLab CI separate, he said, you know, these need to be together, and we, through some convincing, we put them together and found that the CI and the FPM and found that the sum is greater than the part. GitLab's mission as a single application does not preclude it from playing nice with others. So, in fact, we have great integrations with popular tools such as Jira, Jenkins, GitHub, and of course, GitLab integrates with AWS and Amazon Elastic Container Services to give you a one-stop instant software factory. You know, in fact, many of our customers will tell you that GitLab is the best way to get your organization practicing DevOps software delivery at scale. So, today, we're going to show you why do all these people think this. So, we've already discussed that GitLab covers the entire DevOps life cycle. It can help you manage and plan with features such as issue tracking, issue boards, road maps, milestone, et cetera. You'll see these on the manage and plan side in this chart here. But today, we have very limited time, only 20 minutes total. So, we're going to jump straight into the create part and onwards and take you through the entire DevOps life cycle of code as it goes through version control, CI CD pipelines, and then it's deployed and monitored on Kubernetes on Amazon EKS. Yeah, Priyanka, let's bring up that spring app so that we can show the audience how GitLab can make the development flow so much better. Sure. Yeah, let's do it. So, we started a welcome app in spring, but the main page is still pretty generic and we need to update it to the GitLab style. Yes, absolutely. And I already have the code in GitLab, which is what we use to build and ship code ourselves. So, I'm going to go there and let's just take it away. Folks, this is a live demo, so please be kind to me. Okay. So, here I have already got code in this repo in GitLab. My colleague, Dan Gordon, has helped me a lot with this demo. So, you'll see his picture and name in quite a few places. So, I have my code in this repository. Before we jump into making a code chain and taking things from idea to production, I'd like to show you some configuration. So, you will see that in settings, oh, sorry. In operations in the Kubernetes tab, here we have a Kubernetes cluster already set up that works with Amazon. And you can actually add as many Kubernetes clusters as you like. So, if we go in here, what you'll see is that we have a bunch of applications that are utilities that we have already installed here, including Prometheus. So, as we go through this demo, you'll see how you get some of the things that you can see here. So, you can see that we have a bunch of things that we have already installed here. So, you can see that we have a bunch of things that we have already installed here. So, if you look at the cluster details, here you can see Amazon AWS. So, we're all connected and all set already. So, yeah. So, that's my Kubernetes setup. Now, I am going to show you one quick thing before we install the Prometheus pipeline that GitLab offers people so that they can just push code and then it goes through a full CI CD pipeline, and then it deploys to Kubernetes clusters. While doing that, it goes through various tests, security checks, and finally pushes code to Kubernetes clusters on your cloud of choice followed by monitoring for free. AutoDevOps is not mandatory. mandatory. It's just one option that you can use. If you like you can incorporate pieces from auto DevOps into your existing pipelines or you can or you can change auto DevOps to include new things. It's yours to do what you go with it. Now here you'll see the domain I've set it up with this service called nip.io to make it easy. Also deployment strategy wise I have a lot of options. I could do continuous deployment to production or use incremental rollouts. However I am going to deploy to staging and then do a manual deploy to production. This is a best practice so that once it's in staging other departments or teams can take a look as necessary to follow the procedures of your team. So with that really quick intro I'm going to now dive into the code. So I'm gonna go back to this project. Now I want to let me show you the what the page looks like that I got right now. As I said it's pretty basic. Hello from GitLab whatever. We're gonna jazz it up. So I go into the web ID over here. So this is quite nice because even though everybody has their own preferred environments, mine sublime text don't judge. For quick changes it's nice to have something within your main tool chain. So here I can actually access all my files. Now I know that the file that I want to change is Hello Controller. I click that and oh look there's a personalized this says to do personalized this message. This to do is going to be important shortly. So I'm gonna say hello re-invent love from GitLab. I am also going to change this color from green to a beautiful brand appropriate purple. Now I've got a cheat sheet here for the hex code. So oops gosh I hate this one second. Okay here's my cheat sheet. I'm gonna use this background color change. I also will add a cute Tanuki, Tanuki image for that. Again I have some code in my cheat sheet notepad copy hate this. Are you only sharing your desktop or are you only sharing the browser? Just browser. Alright and now because I have finished the to do I'm going to delete this. This is going to be important because as the demo progresses you'll see something related to this to do come up. So now made the changes that I wanted to make and it says here that I have one unstage change and I can hit commit which I do. Now it gives me the diff which is super useful for a quick check. Now here on stage changes it only shows one but what's useful is that when you have multiple you can pick what you want to actually go to stage. I'm clicking stage all changes. Hit commit again. Now I'm going to put in a message. Make it pretty. Then here I have the option to commit to master or create a new branch or create a new branch and merge request. I'm going to do that because that's the best practice. I'm not going to change the name right now. I'm going to hit commit. Alright all changes are committed and now we have a merge request to make. This is epic. Okay now I can assign this to myself. There are all these options. I could set up an approver to check this for me. If I had code owner set up there could be auto approvers done. It's pretty cool new feature we have. Now here I am going to check remove source branch when merge request is accepted to just keep things clean. All that is done. Now I'm going to submit my merge request. Excuse me. So now it kicks off a pipeline to deploy to staging. Remember that's what we chose back when we were setting up the auto DevOps configuration. So here a pipeline has started for me. I'm going to click it and here you see the auto DevOps pipeline that I talked about. Now this is where I do a little bit of sleet of hand and have a cake in the oven ready to show. Like a magician I'm going to change things but unlike a magician I'm going to tell you exactly what I'm doing in our GitLab spirit of transparency. So here as you can see the pipeline is just starting to run. So I have a identical project where I've made the very same changes that is available for me. AWS one and here you can see the pipeline has already passed. So this is because pipelines take some time. I'm going to just go through this over here. So build is basically so all this is the auto DevOps pipeline. Build means we use Docker build files or if that's not there, Heroku build packs to determine what language the code is in and then build the new image which is then stored in our container registry. Then in the test section there's code quality which does a static scan of qualitative things that can be an issue with the code. Then container scanning checks your application containers for any vulnerabilities. Dependency scanning looks at any open source code dependencies that you have and makes sure to protect you from known vulnerabilities. License management checks all the open source dependencies that you have and ensures that you don't accidentally accept some open source license that may have gone viral or is just for some reason against your company policy. SAST here is static application security testing and it goes through your code to make sure that any known security vulnerabilities are not present. Then test is the test that you as a company may have created as I had a test holder in my files and that's what's here which can be unit tests, functional tests, all kinds of those things. Now those all have run here. The next thing that happens is we go to staging. Now this is where some cool stuff happens which is that we build a review app and what that review app does is that it makes it possible for you to actually have a live app running on the Kubernetes cluster that you already have. It's an ephemeral instance and you can check it to send people the link to see the changes in the line and like on their devices or however they want to do it. They can also and based on that we can also do dynamic application security testing because that's only possible when it's a running application. So we do all of those things and then if everything looks okay we can hit to production and do 100% rollout. Now if you remember we decided that going to production was going to be a manual decision. That's why it is like that over here. So I'm going to click that so it'll kick off a production pipeline. All right now it's working on that as you can see. Now to really understand the value of auto DevOps and all this goodness we should go back to the merger quest because here you see in the merger quest is all the information from this pipeline run. So I see here that their memory changes. I also see that code quality improved on this one point and this if you remember there was a to-do that I deleted and that's what it's talking about. Performance metrics have changed which means we did a site speed.io check and we saw some issues and some improvements. This one is very important security scanning so I can look at all of my security report in one go. I just click that and here we are. Here you can see okay I can expand this right away. I see there is one vulnerability. I click I get more details. I can click these. I can dismiss the vulnerability or create an issue to help people move forward with this. Dependency scanning worked really well. Now container scanning saw all of these various vulnerabilities and I have the option of either dismissing, creating an issue, learning more. Now in DAST here it also did the same thing. We have one thing that we found. We can learn the descriptions and then we can, sorry my screen is awful, and we can dismiss or create an issue as with the others. Alright so with that all said let's go back. Here license management is another really useful thing that you, oops sorry manage, I should not have clicked that, I apologize, but right okay here that was my mistake forgive. Okay here I can view the full report of licenses as well which is the open source licenses that we are using and here you see the whole list, again you can blacklist, you can learn more, you can blacklist, you can approve, you have all these options that you can take care of. So oops sorry sorry let me go back to my where did my merge request go? Oops close the tab. Oh right sorry and then alright so the same goes for license management all that is done now this says here that it was merged by Dan a day ago which is the case because as I told you this is a cake picking in the oven. So this is already now what we can do here is go to settings and check our, sorry not settings I always make this mistake, go to environments and check what is our setup on the Kubernetes side. So here you can see that we have the staging thing 100% complete all set up and we can look at the review app open live environment which I had and look these are the new changes I've made look at this we have it all different and pretty but the get lab colors so pretty right so much better than the old one so from here I know everything's looking good and I'm pretty happy and I can proceed to production and hit rollout now from staging. Oh sorry then I can deploy and I hit rollout 100% what this will do it will kick off the production deployed to production pipeline and let's see I guess it's gonna work shortly it's still going so we wait and we wait. Do I refresh? Yeah I'm gonna refresh my page just to see the new thing kicked off. If you end up that way having a stall like this you can talk about like the what is these little green boxes right how they relate to Kubernetes. Now here by the way you'll see these five boxes these show that I have five instances of the Kubernetes clusters running because that's what we assumed should be the need for the load we can increase and decrease it with configurations over here. Now in terms of my deploy it should be I'll go check the pipeline maybe. Oh go to it should be done so if you go to production and look at the look at the app then it should be the new stuff. So now I'm gonna look at open this and look it's purple and gorgeous and it is and now you could also potentially go to your original one that you brought up your laptop. I can also really do this and let's see what happens. Oh there we go so it's all working we're all set and we know that now. Now all this is ready and here's the final kicker. I am going to go to monitoring tab and I get to this performance data page it always takes a second so this is not abnormal because it's gathering the data live from all the different systems and here we are. So here you get system metrics about your part average core usage and all of that. So you see these various lines which show you the various deploys and it's really useful because so for example there's a spike over here and if this was a problem you have the option to click on this and check out what exactly changed to and where oh like so this was a change by Dan Gordon so we know like and we can see the change exactly here so gosh Dan just kidding people all of this it's all good sorry waiting for the performance again one second I'll do this as a new term next time same for the memory usage we see response metrics from engine X error rates which are important and again you can debug right from here if you see a problem and because it links to the merge request where the change was made and that way you know exactly where the problem was and you can debug quickly because you know what the issue was so all that is to say that sorry yeah so all that was a quick very quick tour through the GitLab software delivery factory we went from picking up looking at a repo of code making a change there and then running the CICD autodevops pipeline doing a bunch of tests and making sure it was very well tested from a security perspective looked at a beautiful review app that we could send to anybody that we needed to we pushed from staging to production and then got free monitoring from Remethias out of the box so that is software development operations and security with GitLab if you're interested we would love to talk more with you please do stop by the GitLab booth 2608 hope to see you soon thank you so much let's stop the recording now