 And the recording has started. Cool. So welcome everyone to Sales Enablement for Thursday, March 21st. I'm Dan Gordon, Technical Marketing. And we're going to today, for the most part, be covering a review of a click-through demo that is available to show GitLab across all of its capabilities using the auto DevOps feature as the focus. But before we do that, we're going to have Tina hop on real quick. And what you're looking at, we're just going to talk a little bit about some events that we have coming up that we're pretty excited about. And we'd like to get guys to check out and help us out with. So Tina. Great. Thanks, Dan. I will not take too long today for all that know me or don't know me. I'm Tina Sturges, Partner Marketing. I wanted to enforce and reiterate because I'm sure you have heard from your field marketing team already that we have Google Next coming up in just over two weeks, starting on April 9th. We have a big sponsorship there. Couple things I wanted to show you. We do have an Epic here within our GitLab system. That's what you're looking at here. The Epic has, if you're interested in providing your customers or your prospects a discount code, please go there. The discount code is there. It gives them $400 off from the full rate. So please take advantage of that. It looks like we have up to 100 discount codes to leverage for that. Moving on. So what does it mean for us at Google Next? And how can you in field sales help us? So we have two main areas that I need your help in. And we are urging you to do that, which is we have a conference dinner that we are sponsoring on Tuesday, April 9th. It's in the evening at 7 o'clock. We have rented out to the entire Feng restaurant, as you can see here at the location. We have a maximum capacity of 60 people. I would love if you guys can help us fill the place completely full without all GitLabbers or Googlers. So at the end of the day, I think that if you need help, there is information in the issues on how to invite. Within the planning doc is once you get the people to actually be invited, you'll go to the planning doc, like you normally do with any other event. You'll update the specific tab, and then Emily Lures will take that to the next level and make sure that they have a formal invite. The other area that I strongly need your help here is Google Next meetings. So these are our on-site meetings with leadership and executives. Again, this is something that we have a ton of different executives and leadership. I think we have Eric Johnson is going from the engineering team. We have Brandon Young on the alliances team. Sid will come in if we can book some meetings. We also have Todd Barr. We have a ton of people going to this event, and I'd love to get their calendars packed with customers and prospects from your side. Again, this isn't any different than we do it before. The planning doc has all of the information for you. We are meeting at a particular location. It will not be on-site at the event itself. We actually have a meeting room at the St. Regis Hotel, which is just across the street from where we're at in the Moscone Center. So we are putting together some documents in addition to the documents that you see here to help you do email invites, et cetera. So those will be forthcoming as well. And I did want to tell you one thing. So those are the two things that I have the needs for, so the dinner and the meetings on-site with leadership. I also want to tell you we're trying something new this time at the booth. So instead of giving big giveaways at the booth itself, we're actually going to do a larger giveaway or raffle for an iPad. So anyone who comes to the booth can get an iPad. I think we're giving away one of those. And then what we're doing is we're taking, if you look here for the badge scan, we're gonna donate $5 to $10 on behalf of the person to a designated charity. So I think that this is a super fun way to get people excited. I think that it'll actually create a buzz. Love the fact that Emily, Kyle, and the team has put this together because it's very different. And being the charitable person that I am, I would 100% hands down go to that booth to give to my charity of choice. I don't think we have the specifics of the designated charity yet, but we will definitely let you all know. So that's definitely a fun thing on Google Next. I'm done, so I'm going to stop my shared fan and I'm gonna pass it over to you for your regularly scheduled thing. Thank you very much. Cool, lots of exciting stuff. I love the charity idea, that is super cool. So now what we're gonna do is we're gonna cut over and take a look at, I'm gonna show my desktop here. We're gonna take a look at one of the available demos that you can do at the booth or if you're sitting with a customer. I think Hayden's had the experience at one point where he was just chatting on the side with someone he met at a conference and maybe it was on a plane, I don't remember Hayden and you're able to pull this demo out and kind of show them some of GitLab and what it could do and they were like, wow, all right, let's talk. So we're gonna go through that demo or one of those demos. I'm starting here on, actually I'm not gonna start there. I'm gonna start here, which is nowhere. You can find this by doing a search for GitLab demos and the first non-commercial link that pops up is demos at GitLab and that is our marketing page that has all of these demos that has lots of videos, overview, information, et cetera and what we call the click-through demos and that's what we're focusing on today. These click-through demos, there's one that's new for secure capabilities which I will cover in a future training or enablement. There is a auto DevOps run which is the full version of what we're gonna cover today. This auto DevOps run takes you through from planning all the way through, a little bit of planning all the way through to monitoring and goes into details on each of those steps. But if you don't wanna do that whole 18, 20 minute demo, there's also a, there's also setting up of GKE and whatnot but there's also a auto DevOps run short and that's what we're gonna look at today. You can actually run it straight from here without downloading anything. You can jump around, et cetera. But you can also get the actual file and you can cache that locally and that's what I've done over here. So here I'm sitting with the auto DevOps run. I've got it cached locally so I can be doing this disconnected and we're gonna hop into that and I'm gonna walk you through that. I'm gonna go a little bit fast through it so I'm gonna talk kinda quickly just in the interest of time so there's time for questions at the end. This should run depending on how much you talk and how fast you talk anywhere between six to 10 minutes. So we'll hop into that. So this is a view of a feature capability in GitLab called auto DevOps. We show this because it does a good job of showing across all the different stages and many of the different stages. We're gonna start by talking about the complexity of tool chains which poses a challenge when companies are trying to achieve DevOps or to basically DevOps are not deliver value to their customers more quickly. They start putting together lots of different pieces from lots of different point tools to make up their pipeline, their delivery pipeline. And there's lots of conflicts and there's lots of integration work that needs to be done. And what we find is that companies get bogged down and they don't achieve the value of delivering value to their customers quickly because they're busy setting up their tool chain. GitLab by contrast has capabilities across the entire tool chain all the way from managing to monitoring and soon defending. And all of this is in one tool all pre-integrated ready to go so you can put down GitLab, put your code in and start deploying your application into production. Now I'm gonna pause here just for a second to point out something here. I have set this up so that there are flag points along the way like create and this is a change since a previous use that I've gotten feedback on, et cetera so that you can jump to certain points if you need to try not to do this because we kind of want to tell a story. It's not about just showing features it's about telling a story. However, if someone comes in and says, hey, show me what you got on monitoring, right? If there's a dot hidden next to it like under create verify secure release configure and monitor then while the slideshow is running a click on one of those will jump you to that point so I can jump to monitoring for example and I can go from there. Getting back is a little bit more difficult. So we're back here. You've just talked about how GitLab have capabilities across the whole development lifecycle, DevSecOps lifecycle. And we're gonna talk about auto DevOps and so this is gonna focus on the orange bar here it covers from create through monitor. So what auto DevOps does is it sets it up so that you have out of the box pipeline that's ready to go that does a whole bunch of verification and validation packaging and deploying for you so that as a developer you can just commit and get lab auto DevOps will take care of the rest and start with create we're going to start here and I'm gonna point out that this is just source code and maybe some project files. There's no pipeline file. There's no Docker file to define how we want to do anything with the source code. Let's go ahead and pop in and do a quick edit on the hello controller.java. We're gonna do that in our built-in web IDE because that web IDE enables you to do everything without having to configure your local environment. It's all in the cloud or all on the system all through the web. So I'm gonna make some changes here to the background color. I'm gonna take out this to do message which is a comment. I'm gonna change the message to something like GitLab and then actually add a logo but let's go ahead and make the commit on these changes and we can see automatically shows us the diffs here so we can do a quick check and make sure that this is what we want. Part of the value of the web IDE is I can pick which files I've changed that I want to commit so much like Git on the command line except it's visual. I can be very selective about what I want to push forward. So I'm gonna head and select the file I changed add a quick message and then I'm going to commit that before I do any to decide do I want this to commit straight to our master branch which is not a best practice or do I want GitLab to take care of some things for me? I'm gonna have selects down here to have it create a branch and a merge request. Now this is a best practice so that GitLab automatically put my changes into a separate branch so that I'm not affecting what everyone else is using and it's gonna start what we call a merge request once I do the commit. And this merge request is the centerpiece around where we capture the results and all the information about the change that we're making. So this is also where the discussions will take place and approvals so that will help us to decide whether or not this change is verified and validated to go forward into production. One of the things I've checked on this with all these settings is to have it remove the source code branch after it's been merged so because it's a whole connected system we have this ability out of the box. Once this is merged into production GitLab will go back it will clean up the extra branch that was created it will actually go and clean up the Kubernetes review apps and make sure that you're not wasting resources on that anymore. We'll talk about that in a minute. So a lot of great things come out of that single checkbox to keep your repository and your system clean. Then I'll go ahead and submit the merge request. And this is gonna take us to the verify and secure stage where we're going to look at the pipeline. If pipeline gets kicked off here's the merge request and you can see that it's already identified the pipeline it's created it and it's put it up here so I can start tracking it from this point and we'll see that this gets filled out with more information in a little bit. Remember again that as I would take a look at this pipeline is doing all of this we haven't defined anything this is all out of the box capability. You can automate or customize the pipeline you can create your own pipeline to do whatever build you want on your own but this is what comes out of the box. So auto-dev also detect your language and it will do a build on it and create an appropriate Docker image that is all the process of figuring that out and doing that is automated. Once it's done that it's gonna kick off a series of tests there's six in a row here that are gonna run in parallel it will scale out to do that and those tests are the code quality checks again remember this is all part of GitLab so we didn't add or connect or integrate to anything this is all built in code quality checks we're gonna do container scanning so we're gonna look at the image that we replaced our app in because the container is our application environment and we wanna make sure that that is secure not just our code so we're gonna scan for vulnerabilities in the container image we're gonna do dependency scanning which is gonna look at all of the software that our software uses all the dependencies and it's gonna check all of that for vulnerabilities as well so that we're checking not just our code but everything else as well it's gonna do license checks oops, sorry it's gonna do license checks where it's gonna look again at all of the code that all of the code that our code is using it's gonna check the licenses that this code uses so we don't accidentally do something like adopt a viral open source license that makes, for example that means we have to now give our code away for free and that anyone else can use it if we don't want that as a business we can set up a policy against that and license scanning we'll catch that and flag it and then we're also gonna do static application security testing fast and what that's doing is that's looking through our code for known vulnerabilities things like buffer overflows and things that we can catch by looking at code and it's gonna flag those so those can be fixed and not passed into a production environment we're also gonna then do the developer tests so these are any tests that's developer defined unit tests, functional tests those can be put into the code base our Heroku build tax will find that GitLab will find that look at those and then run the appropriate tests once it's done all of those tests it's gonna move on to the review app and now the review app is a little bit of magic here where GitLab and Kubernetes together are gonna work to take that change sorry, that build artifact that has all of the tested and verified code and it's gonna put it into environment that's up and running that's specific for this change so we haven't pushed back anything to the master branch or the default branch this is just each developer's code change now running as a live application so that the developer can interact with it stakeholders can interact with it and verify that the changes are correct as well as this enables us to do things like dynamic application security testing so DAF is gonna look for things like cross site scripting and other vulnerabilities that you can't find by just looking at the pieces of code but you have to find looking at everything together running so we're able to do that again on each developer change because we have this environment automatically set up another thing we can do because of that is performance testing so we're gonna run site speed IO and check on staff and baseline and then measure against that baseline for did this change actually create a slower interface for the user so what is the user experience after this change has been made so lots of great data lots of tests but it would be not great if you had to go back and dig into each of those jobs to find the information so if we wanna review that one of the beauties is it all comes back to that merge request again so this was the pipeline the merge request and remember we had the pipeline here and we still have a summary of it we've now got the link to the review app so I can go to the review app and see yep those are our changes they look good I can get I can look at the measurements on memory usage on code quality reports so it's found that I made that change there and performance results I can get all from here the information on the security tests so I can see here that it found a vulnerability I can actually click into that get more information about the vulnerability create an issue on it dismiss it so I can take action from here for that and then once I'm past all of these and I've verified and let's say that I'm good with the results and whoever is an improver is allowed to say who's allowed to merge can go ahead and then say merge the code and once that merge happens we're kind of moving into our release phase and let's go ahead and we can see that in the pipeline screen that actually kicks off a new pipeline so let's take a look at that new pipeline looks pretty much the same it's doing a lot of the same tests except now instead of going into review app we're going straight to production now that's kind of continuous deployment out as best we've made some code changes we sent it through the pipeline that got validated and then it was merged in and then went all the way through to production now let's take a look at a result once that's pushed to production we have our production environment that we're tracking we can see the changes and the commits that have happened to that production environment I can also go to the live environment and I can see again that same code but now it's actually in the live environment I can also drop down here and get more information about the scale of our application so I can see here that there's a single pod Kubernetes pod that's running our application so maybe I'm not good with that okay that was good for the getting it out there but I'm expecting a load on this so we're going to go ahead and increase it I can go into settings I can define the number of replicas I want save that variable I've set it to five and then redeploy and once it redeploys it's going to go ahead live start showing me as it builds out and then start filling out those extra pods until I get to the stability point where I've reached the desired number of pods and I can see that in my interface but that's not all we also monitor so this application remember I didn't set up or configure any of this but we deployed it through GitLab so automatically it's now set up for Prometheus monitoring so we can go here from the environment and we can take a look at the app itself and see the monitoring information about it out of the box we're getting information from the Ingress proxy about HTTP error rate latency the throughput stats I can also get information about the Kubernetes cluster the infrastructure that I'm running on pod average for CPU and memory usage, et cetera and I've also got these lines now these lines are important because this is really cool we're actually correlating the deployments that we've made to the behavior that we've monitored so I can dig into this line and I can see, okay so there was a deployment that happened at this point I had a memory pickup of all of a sudden so I can go and I can actually look and get the details about what that change was who made it, when it was made so that I can take action or investigate more I'll hop back to monitoring and then finally let's say that I'm not comfortable as a customer I don't really wanna go straight into deployment straight into production as I get my tests done that's not a problem that's the default mode that we have it set to but you can also configure manual rollout by going to the CICD settings for auto DevOps and then simply checking to have manual deployment into production instead once you do that we'll go ahead and run a new pipeline against master because that's what actually sends us to production what we'll see is that we get a similar pipeline but now it's going to staging it's gonna stop and wait and let us look at that and then allow whoever has the access to rollout incrementally 10, 25, 50, 100 into production and that is in a nutshell auto DevOps functionality but showing capabilities across all of GitLab okay we're gonna stop and check for questions that's all done let me stop the recording