 Now, I am excited to introduce William Galinas Arias, a technical marketing manager at GitLab. William was born and raised in Columbia where he studied electrical engineering and specialized in digital electronics, and he spent time as an exchange student in Czech at the Czech Technical University studying data science. William started a professional career working at Intel as a field engineer and then Oracle as a solution architect in Columbia. After some years in the industry, he became a student again in Prague in the field of machine learning, and then he jumped back to the software enterprise, enterprise software industry as a solution architect for CI technologies for Europe. Currently, William has served as an advisor to a Colombian startup focused on building NLU chatbots and web applications, and at the same time an engineer in French company developing bots for automation. In his role at GitLab, William is responsible for technical storytelling and product demos. Today, we get to enjoy one of William's demos as he shows us the DevOps platform. So hello, my name is William Arias, and I am a technical marketing here at GitLab, and I will introduce you today and walk you through the story of our GitLab DevOps platform. So what is the agenda we want to cover today? I want to share with you an idea and some steps, tentative steps to execute it, the tools to make it real, to make it possible on how these can bring everyone together, and how can we do it in the DevOps platform. So you can think of this as a project of an idea that you have for your startup or big company. It doesn't matter. It starts with some idea, and I want to share with you what was mine. So in this case, let's say that I want to create a e-learning application, which is a web application that one of the requirements is that it has to be cloud-native, meaning that I want to deploy this to a Kubernetes cluster, so I can enjoy all the capability from Kubernetes for scaling and horizontal, vertical scaling and so on. So this application needs to be accessible from different devices, such as mobile or desktop. So I will now show you that any time that you have an idea and you want to execute it, and if you start listing all the items or the steps that you need to make it possible, even if it's a simple one like this one, web application for an e-learning website, we need to think of planning stages, like I have to define some milestones, what are the tasks that I have to do there, the sketch, some UI, how is it going to be the interaction with the end-users, architecture of the application, and whenever I want to make contributions to the application, how, what would be the workflow, the testing, how can I make sure that I don't introduce security vulnerabilities into my code, and then how can I deploy it? Will I use a container wave, or what will be my strategy to deploy this application into production? So how many tools do you think are needed to execute or to work on a project like this one? So the answer is that there are many tools, but more than tools and systems, also different personas, different people are part. So it's people, processes and systems, and in application, I guess it can easily scale that you need input from business teams, you need the developer and you need security operations all in the same page and under the same umbrella to make something like this happen. So what are those steps? I outlined a simple process here, where we can start where we create a project, we define the milestones or tasks that needs to be done in order to execute that idea. We code, we have to review the code, test it, ensure that the quality of the code is not decreasing, building the images, review these images, and finally deploy it to Kubernetes cluster and have some dashboards or monitoring to know how we are doing in these environments. And this simple process here can easily bring different roles or different personas that are part of this story. So how does this look like? So do you remember I was mentioning an application, so a web application, so this is the code, this is the project, the GILLA project where the application resides. And let's say that I here as a developer, I have the list of my issues. And one of the issues that I can see here is that we want to change the background of the main web application to highlight the subscribe button. So how can we do this? So a simple way here is that I can see all of my issues and also as a developer I say, okay, now this is, I can see here this is due tomorrow. So I want to work on this issue and I want to give priority to it in which I want to work on it right now. So I give priority to it, I go back to the issue and I will create a merge request which in creating a merge request means I want to contribute code in this case in order to make a change of this image in my web application. And to do that here in the merge request, I can because this is a quick, quick change. This is an easy one, let's say. So I can make use of the web IDE which is an integrated environment where I have access to the files of my project. So in this one, we have a Flask application where the part in charge of the style is a CSS file that is separate from the business logic. So I know already and we have uploaded to the repository that this is the image that we want to use. So I'm making the changes and I commit to it and here we can see that we have the diff of the code and I want to say that this change is changing a background image. Remember always to try to write a meaningful commit message. So I commit on the changes and this will trigger a pipeline. And this pipeline that is associated to the original request, we can see it here now. So here is where one of the things on the magic that I love starts happening. As you can see here, what I did was, we started from an issue. We want to change a background image and what we did is, okay, let's change it using the web IDE and I committed the changes. And this starts a pipeline that what this is doing is automatically is building my image which means that this web application because we want to deploy it to Kubernetes is reading a Docker file and is collecting the requirements that it needs to work properly. And all of these things are happening right now and automatically as a result of my commit of changing an image. So there are different stages here. As you can see, we are building the image and one very important that is the testing one where what I'm doing is running different security scanners in this pipeline that they are ensuring that with this commit and the code that I am contributing, I'm not introducing any security vulnerability to the project. Among those that I can mention here, we have SengRep that is static analysis. We are also adding different custom testing code that I want to do that makes sense for my project. Secret detection, it can happen that sometimes you forget all developers can forget and they commit credentials, API tokens that you don't want among others. So we also have a false testing and code coverage and very important that I want to highlight is this review stage. What we are doing here is that we create an ephemeral environment where I can touch the application I can work with it and try it. And if I am happy and it passed all the steps I will merge it to production. So all these scanners and all these things that get triggered by my commit of changing the image, this pipeline it will take some time to finish. And so let's go to another magic quest that already finished and in order to illustrate what will happen in this pipeline that you saw is running, I will show you one that already finished and we will walk through the steps that it went through and how it made it to the main code base. So similar like in the previous case, so this pipeline here that was already executed it went through all the stages and all the stages are green which means that my different, I didn't introduce vulnerabilities to the code. And one of my favorite features here is that associated to this pipeline there is this tab that is called code quality which tells me that for this specific merge request for this specific commit, this is a report of what is the code quality and it tells me the exact line of code where it found something that might be degrading the code quality of the project. So for example, in this one is telling me that it has cognitive complexity because the function is too long. So if I click here in the file it will bring me directly to the line of code where it found that for example, I could consider refactoring this function and making it shorter. So this is because it has some cognitive complexity. So all of these things I can see straight from the pipeline that's just finished. So I know that in the code reviewer stage if I am a person that I'm reviewing this merge request I can decide or not, I can decide to say this please ensure that you address all this code quality warnings before we accept your contribution or I can say, okay, this is not necessarily critical we can move on with the merge request. But what I'm doing here is that I am ensuring that the code quality of the project will not degrade with every contribution and that I am not in producing vulnerabilities into my code. So this thing is very important because if you think about it and if you go to see some reports, the cost of remediation of a security vulnerability is cheaper at the coding or create a stage. So it's better that we catch it here than we catch it when we are doing integration or when we deploy to staging or even worse when we deploy to production. So this is giving me the opportunity that even before I accept the changes to a main code base, I cannot in advance if it's gonna degrade my code, or if it's introducing code vulnerabilities as we can see here. So another thing that is important that I wanted to highlight with this merge request is that it has different rules that we need approval. So we can merge this into the main code base. In this case, a custom role just to illustrate the point of that you can create your own rules is that we have code owners enabled and whenever there is a change to the CSS file, what this is telling me is that we need approval from this person so we can merge the changes into the main code base. So this one was approved and we see it in the merge request view that it can also open the door for collaboration where the person is telling us I just checked the application and it looks nice. And what it means by the review app is that as I mentioned before, when we are making a contribution to the code, the GitLab Kubernetes integration is giving me an ephemeral environment where I can try the application before it's released to production. As an example of that, like in this case, it will create a button like this one that says view app and here what I have is access to the application and how it looks like with the changes that I just committed. So this is the old image and this is the subscribe button that was describing the issue that we want to change this image to enhance the contrast of this button. And why am I introducing this little story? Because now when we introduce this change to the application and if I want to see how is it going in production, there is a set of metrics that I can monitor for this production environment. So one of them, or many of them, is that first of all, remember one of the requirements is that the application had to be cloud netted. So what we did is that the application was deployed to Kubernetes. So if I want to see the different system metrics from my cluster, I can see them here, core usage, memory usage and so on. And one of them that I can configure thanks to GitLab integration with Prometheus is that I can create my own business metrics and these business metrics, they can make sense to your use case or business. In my example, and why I was emphasizing about the paying attention to the click on subscribe is because I have instrumented the application in a way that that button that says click on subscribe is instrumented, meaning that every time that someone clicks there, I am capturing those clicks and plotting them here in my monitoring dashboard under this custom business metric. So this is only to illustrate that for this use case, we said what, and this is what I was mentioning about bringing different personas for business, they want to see that the business is going in the right direction if people are clicking on subscribe because that means that it's driving traffic that will eventually end up in a sale. Someone enrolling and someone paying for some course. So that's business, but as a DevOps engineer, you want to make sure that your job and the things that you are doing are taking care of the business as well. And how can you know that real in a really fast and easy manner? You just come here to the monitor and metrics and you can have real, sorry, in real time, a very fast glance of how is it going in one of the metrics of interest for the business and if it's running, if this is up, if it's down, and how is it going, how is it doing after different deployments of the application? So this is just to illustrate the point that you can instrument your applications and have under the same application, under a single UI, have access to these different metrics that are part of the monitoring stage. So doing a little recap, we went from having an idea that was expressed in an issue, making a, creating a merge request that changed the code. This code went through different pipelines, sorry, through a pipeline that had different stages. In this case, this one that we ran and we were using one that finished before as an example. This went through different stages that make sure that we didn't introduce vulnerabilities into the code and deploy it to a staging and production environment that was instrumented in a way that gave us access to this infrastructure monitoring when I can define my own metrics and see how my application is doing in productive environments. So this is how in the stage of the story that we are now. So now let's put the hat of someone from business that imagine that you are a project manager or someone that you are asked, tell me what is the return of the investment of my DevOps strategy? So it's when you want to answer this question, this might be very difficult to answer, but thanks to the GitLab DevOps platform that we have a single user interface and a unified data model, this question will become easier to answer because you can come here, for example, to CICD and using different metrics that the industry has found that they are meaningful in order to assess the maturity in the DevOps and have an idea of your return of investment. You can see, for example, the deployment frequency, how many commit to production are you doing per week, per month or in the last 90 days and the lead time changes. So these two metrics can give you an idea that you can measure the ROI or your DevOps and you don't need to integrate yet another tool to measure this. Thanks to having all in a unified data model in a single UI, you can have access to this real quick. So in addition to that, in the different stages of delivering software here in VolveStream Analytics, we have different metrics of how long is it taking for my contributions to move throughout the stages that we make it to the main code base. Why is this important? Because now let's think in terms of a project manager, you can easily come to the different stages and find where probably, if there is a bottleneck and if there is a bottleneck, so what can you do in order to improve it and deliver software faster and better? So one of the things that I like the most of having all of these things under a single UI is that this really makes your life easier because if I want to change something, if I want to change code, I only have to worry about the code itself, the changes I want to make, and then all of these platform will take care of the testing, deployment, making sure that I'm not introducing security vulnerabilities, and all of these automation can be attributed to one of the famous GitLab CI YAML file where all these things that you saw in a visual representation of stages, they are defined here using YAML in order to reduce the barrier of adoption to try these things that I just showed you, there are different tools like the pipeline editor where before I commit the changes with this YAML file, I can have a view of how the different stages will look like, what are the dependencies between them, for example, I cannot deploy to production if I don't have a staging ready and I cannot review my application if first I didn't do code coverage testing and I am unable to know the performance of the application if it's not deployed in production. So all of these things is this visual representation is expressed in the YAML file and I can have access to it before committing changes to this file. In addition to that, I can also have this view where I can check if my syntax is correct so I don't have to make changes, commit them to later find out that, oh wait, there was additional space or some error that might slow me down. So through all of these tools, what we are doing is that we are making easier to develop, we are making the development that in a way that you care more about the code than the orchestration of tools or systems. So let's recap a little bit this little merge request that I did changing an image that went through all these steps can be represented in this process and at the end, all of the people that were involved here you can think of more personas. I was just mentioning some of them like from business side, the project manager, product manager, DevOps engineer, they all are under the same umbrella and they all have a single UI where they can see the status of the project and its behavior in production environment. So takeaways that I want to highlight from this demo is that one of the benefits of using DevOps platform is that we have visibility into the DevOps value streams and this can help you answer questions of or what is the ROI of your DevOps strategy for example and finding the bottlenecks or where is room for opportunity, room for improvement where you can address these bottlenecks and make changes in order to deliver software faster and better. As you could see, it was very fast to make this a small change thanks to all of these tools that are pre-integrated and having the peace of mind that when I change it something it triggers some security scanners and code quality scanners that will enable someone that will review my code to do it faster because if the test pass so it means that the code quality for example was not degraded. So this enhances velocity and collaboration among between different stakeholders and security embedded. So this is one of also my favorites because it's very difficult to keep track of all the vulnerabilities that may pop up when you are coding and by doing this I just make sure that if I introduce something it will be caught in the code creation during when I am coding under the creative stage and not when it's more expensive to remediate the security vulnerability. And all of these advantages that I just mentioned they are all possible thanks of having a DevOps platform that has one user interface with a unified data model. Okay, thank you for your attention.