 Okay, in this short video we're going to take a look at what a traditional DevOps stack looks like and what that means to teams to stand up a new project and get CI CD working and then contrast that with GitLab and our vision for complete DevOps. So here we look at the legacy state, set of tools that many enterprises use for DevOps and so let's talk about a brand new project that's getting started by a developer. They're going to have code and start creating this new project and of course the developer is going to be uploading that to their source control management system, let's say in this case GitHub Enterprise. So we'll need a new project there and to make sure that the right people are credentialed and have access to that project and then we might hand off that project to the infrastructure and DevOps team. They're going to create a new channel in Slack to help with ideation. They'll create a new project with the right credentials again matched up in JIRA so that we can manage the planning of this project. They'll create a new project or folder in Jenkins. Make sure that that has the right credentials to connect back to source control. Then we might make in the DevOps side of the house, we might make a new project or write prod files for puppet and chef or chef to stand up environments for this and maybe we include those in source control. Maybe we don't. It depends on our processes and then for production, we're going to have to stand up a new instance. We'll have to spec that instance, let's say in AWS or Kubernetes. We'll have to create that instance, make sure that the credentials to get all the way back are ready for that instance and then maybe create a new project in New Relic for instance to monitor that production instance. But then also if we want to dockerize and kind of take this into the cloud, we're going to have to create a docker file and maybe have Docker Hub to store that or maybe in addition to that have an artifact store in Nexus or Artifactory. Then we're going to connect the build process into that channel and Slack that we created so that we can actually have build statuses be able to be visible by the developers. When there's artifacts or those Docker images, we're going to want to factor those into our puppet and chef scripts. From there, we're also going to want to focus on code quality so probably at build time Jenkins will push code quality metrics to sonar and then we might want to connect that again back to Slack to understand how code quality is changing as we're making changes. And then, you know, we're going to want to again put the monitoring into Slack as well so that production issues are clearly noted back to developers. And so this is, you know, 20 plus steps to set up and connect and wire together this brittle architecture. And in many organizations, this can take a long period of time. It can create different people if someone manages Jira and someone manages source control and someone else manages Jenkins and someone else manages production environments. Now, you know, we're talking about multiple roles involved and their shared time and, you know, when their availability is to stand up something new. And so that contrasts with GitLab, of course, by saying, you know, in a mature state, GitLab controls everything about our software delivery pipeline. And maybe it's still connected to Slack because we want to do some chat ops, but the developed code goes right into GitLab. From there, GitLab automatically detects what kind of code it is, builds it, automatically uses Heroku build packs for testing and code quality, automatically dockerizes the app for us and deploys it into a Kubernetes cluster with auto review apps and auto deploy. And because it's deployed in Kubernetes and we have Prometheus faked into GitLab, we're automatically monitoring that code from day one. And so in this way, developers are unable to deliver code faster to production and cuts out that brittle house of cards, traditional DevOps stack.