 then. And we're live. All right, excellent. So having not prepared much, let's see on the fly. So let's talk about DevOps in general, where we've come the last year, where we're going, and then talk specifically about auto DevOps, and then open it up from there. How does that sound? That works. All right, cool. I think I already showed you this last time. The, what's a good place to start? Let's see my pull up our direction page, and then I'm going to search the screen. Okay, so from the direction page, this was, when I joined a year or so ago, I created a vision document for CI CD, and outlined a lot of the key things that I thought we're missing in CI CD in general, and going beyond CD is CD. I just called it beyond CD, literally. That's what I called it, because I didn't have a name for it. And I created this example pipeline to sort of characterize all the stuff. I move this is going to work. Okay, good. And so I mentioned this before, but the reason I love this diagram is not only because complex and scary, but also because when I started, we had maybe four boxes filled in, and now we've got 10 or whatever it is, filled in or 12 or whatever. Basically, we originally had obviously the code management. Can you actually see my mouse? Or is it? We can. Okay, good. So yeah, we had code management, and obviously build and tests. And we kind of did deploy, but not really. Well, since then, we've added review apps, which is really awesome. It's a specific example of deploys, but we also added, you know, more formalized mechanism for doing deploys and actually recording deploys and deploy histories and track of environments and everything else. And we added canary deploys in 9.2. We added code climates in, I think in 93 or maybe it was 92 even that slipped in, I'm not sure. But it was just recent. We added Prometheus monitoring at assist level, I think in 90 or somewhere around there. We don't yet have what I call the business monitoring, which really is just other things other than the system, you know, so revenue or clicks or whatever you care about. That's coming, though. We don't yet have a plan for future flags, but I think it's a really important part. We have a plan for load testing. The Prometheus team is actually leading that, although there might be some things that don't make this related, but unless load testing is the first class thing. And then down here, we have this other sort of dimension of pipelines, which is a relationship of different code, code basis projects. And in 9.3, we're going to introduce the first versions of cross-project pipelines. So really going from, you know, a core thing of three boxes, actually, to whatever, 90% of this is complete. So that's pretty awesome. But it also became obvious that to me, at least, as we were looking at this, you know, I used to kind of think of this as a hard line of developer focused versus ops focused and thinking like, oh, yeah, we'll get you like up into what we'll deploy into production. And we might even watch the metrics related to your code in production. We're not going to just monitor your production app like that's operations. That's clearly out of scope, right? And what kind of hit me a few months ago is why is that out of scope? That's ridiculous. No, we're going to keep going. We're going to go back, you know, past production into operations. Most of the stuff still applies. But it goes further and says, okay, well, not only am I going to be monitoring the system just as it relates to merge requests, what about monitoring the system for network errors, voltages, whatever, dependency problems, whatever, anything that is typically ops related that may or may not involve a developer at all. I mean, some things are just like literally, oh, this is a network operating system, whatever. Something went wrong. And it's got nothing to do with code. Well, in the broad sense code, but not your code, your project code. And, you know, Amazon is down, we've got to reroute to Google, whatever the heck, there's real operations stuff. And it really hit me that we really need to get towards that we need to go beyond that. And then that gave a little bit more of context for, there. For, you know, this thing that I was calling beyond CD, well, you know, maybe that's really just DevOps. So maybe the whole thing is DevOps. I'm sort of really bring the question of, is there a better way to describe this stuff? Start with a little bit of meta here about DevOps. DevOps is hard to define because everybody defines it slightly differently. But in particular, there's two things that we sort of got to keep in mind. One is that sometimes people define DevOps as the intersection. So I actually look up Wikipedia, there's this little triangle here, or sorry, Venn diagram with a little triangle in the middle. And it's like, oh, well, DevOps is the intersection of development operations in QA, which is already confusing because it's not DevOps QA, it's DevOps. Why isn't it just the intersection of the two? But it makes sense, nonetheless, because actually a lot of this has to do with reliability of your code and continuous integration and all this kind of stuff. But so here DevOps is defined as this as the intersection. So there's trying that there's other things that developers do that aren't related to DevOps and operations do that aren't related to DevOps. And that makes sense. And so you then look at this, this DevOps tool chain definition, where they basically say everything from code to releasing to monitoring, that's all the DevOps tool chain. And so then it's like, well, that's everything. That's not the intersection, that's the union of everything. And so I think that's where things get a little confusing when we talk about DevOps. A long time ago, Hayden challenged me and said, you know, I think GitLab is the DevOps tool chain. In fact, then I was like, no, wait a minute, we don't do Opsie stuff. We're like the dev part of that. And, you know, we're it's way too early to do ops. Well, that's not true anymore. We are absolutely part of the DevOps tool chain. We do a complete DevOps tool chain is what I say. We cover from code to monitoring. And I shouldn't actually say complete. We have a tool chain of which you still probably are going to have other components. We're not everything in the shooting. We don't do Kubernetes. There's still parts of your DevOps tool chain you need. But we are a complete thing in the sense of end and from code to production to monitoring. And we do something in that entire spectrum. So from the tool chain tool product description, you can say, well, then DevOps means code control, building, testing, packaging, et cetera. But, you know, that means that everything, everything that we do, everything that a lot of folks do in this whole developer cycle and the whole ops cycle, that's all DevOps. So then again, you get to this nomenclature thing of like, all right, well, but when we usually talk about DevOps, we're not talking about all of your code stuff. It's intersection parts that are the interesting parts of DevOps. It's the parts where we let developers get their code into production easily. That slice, that intersection, you know, in the Venn diagram again, that's the interesting part about DevOps. Having said that though, still as a product company, we are going to deliver things that are pretty squarely in the development side. And eventually we're going to hopefully deliver things that are pretty squarely in the operations side. Where at some point we may have an operations dashboard that lets you understand your dependencies of your network infrastructure and your routers and your whatever. And that's pretty far fetched at this point. But it could happen. Like why not just have this V1 operations dashboard. And then it's not just about the intersection of DevOps, it's the whole DevOps tool chain. So anyway, at least just to get on the same page, there's the two sort of definitions of DevOps that I think are really interesting here. For the most part, my personal interest has been in the intersection pieces. You know, it's the stuff where, you know, we do great code management. We've done that for quite a while. How do we get that code into production? How do we get it into, in fact into QA and with DevOps is a great example. That is squarely in that tiny little triangle in the middle. It's, you know, you need, you get your code, you deploy it, which is an operations thing, but you have it deployed in a temporary ephemeral app just for QA people. QA people could be designers or product managers or whoever, but people who are not just the primary coders and that they can actually quality assurance, you know, or feature assurance or whatever, just otherwise test your application. And so that's, you know, squarely in that little triangle. So that is whirlwind high level, sort of where we've been in a little bit about where we're going. There's, there are a few issues that we're tracking. I'm going to pull up a few of these because we can refer to them later. It's dashboard. All right, let's start with that. There's just big, another thing about ops features that I created a while early month ago now. As we started to look into, like, oh, we've got this monitoring dashboard, but it's still very developer centric. Well, what about taking that same content and slicing it from the operator's perspective? And so we get some of these ops view of monitoring and deploy boards. This is pretty hard to understand because it's intentionally convoluted to show you the complexity of the thing. But the idea is that as an ops person, I might have an overview. For a moment, ignore all this stuff below. Let's just pretend there's only four things. And it's just a really high level. What's the state of my production? You know, in thinking about it, from a developer, I can go into a project, I can then go into the environments and I can look at, sorry, first, yeah, into a project, into the environment, see the production environment for that project. I can see what the status is. But what if I want to see all production environments? As an operations person, I care a little less about the projects and I care about production, how is production? And so think about this as giving me the overview of production. And so all of these little boxes would represent production deploys of projects that you have in your given infrastructure. And again, it's explicitly convoluted because we had just introduced subgroups. And I want to make sure that this mechanism expanded. So even if you look at this, and then just ignore all this stuff below and say, all right, well, here's all these top level dashboards. And then here's like one level down, which is already still pretty complicated. But let's say your marketing organization had different properties than your other developer operations, whatever. And you'd be able to really quickly see what the status is. And if something's read, you'd be able to click down and see stuff. And you'd be able to see graphs like this, which again, we already provide, but from the other angle, where you're looking at it from a project perspective, or as a developer, I'm looking at the deploy, saying, oh, how did my deploy affect my performance? But this is going the other way around and saying house production. And how is anything wrong with my entire production suite or whatever. So this is actually really just sort of scratching the surface of ops views of things. But I think it's going to be really much, much more important as people brace DevOps. And you want to be talking the same language as your developers want to be talking same language as your operations people. Or frankly, in a lot of organizations, it's really the same people. And there are no separate operations people developers push code to production. And they're paged if something goes wrong. I've worked in that environment where we basically disbanded ops. And it was awesome. And incredibly hard in some ways, it was a hard transition. But DevOps also totally different dimension but has multiple definitions there like is DevOps, the developers and the operators, or is it one person now fulfilling two roles? At any rate, either way, you want to be using the same tools and you want to be able to point to whatever a memory bump here, for example, and your operations people should be able to see that same memory bump. But if they're using completely different tools, they're using New Relic and Datadog and whatever, that kind of sucks. So let's give them the same tools. This is just a slightly different view, actually of kind of our existing environmental stuff, but just merging the stuff a little bit better. So you can actually see the health of each pod. This is more another sort of ops view thing where there's multiple pods running your production environment. There's no single memory usage. There's an average usage or a max usage, but there's lots of different pods all with their own middle memory usages. And in fact, there could be like one pod that has some, you know, egregious amount of memory, but of course, in GPU or something, there's something wrong. You know, that's going a little farther than we've really planned right now, but the idea of like digging into pod health and all this kind of stuff, but that will come. Let's see what else there is. Doesn't have any pictures. It's not good to talk about. I think there's another, let me dig into some of these because I think some of these are awesome. I particularly love this proposal and I really want to see this happen soon actually. So we currently have environments. If you haven't seen one, I'll let's see. I know I just made one. I literally just gave this demo a long ago. So this is what the environment page looks like today. It's just a list of environments with, you know, the last deployment, which the number doesn't really mean a lot, but the picture might tell you who deployed. So that's good. The commit. So here I can see that it's running the same shot as staging, which is kind of nice. I can see the deploy board and I can see, you know, that this has been, if there was a deploy ongoing, I'd be able to see the state as this rolled out. We don't currently show you the health of these pods once they're deployed. That's all we know is that they are deployed, but we have discussions at least of how to like, oh, well, if a pod is failing, we can sort of, so this is all, this is how the environments view is today. It's centered around, you know, sort of the deployment history. And if I click actually on, there's nothing there. Let me click on this one. Maybe there's always two deploys. So here there's a history of deploys. And this is actually really valuable because I can see who deployed things, how long ago. So if something went wrong in production, I can see like, oh, it went around. There's two hours ago that this happened. Okay, great. Who deployed something that it's a roundabout way of digging into that information, but at least you have it today. It's also really great for being able to roll back really quickly. If you do find a problem in production, I can just really quickly roll back and then let developers have some space to go and figure out what went wrong. But I can at least go back to a known good configuration. But this issue turns all that same kind of information, turns it around, and has frankly more of a DevOps view of the thing. The idea I take the same application and instead of just looking at a list of environments, I'd be looking at columns. Okay, that alone is such a big deal. This example happens to show two staging environments. You can even just ignore that for simplicity and pretend there's only one. But there would be lots of review apps and some number of staging environments and production environment. What's cool about this though is instead of just showing you the shaw, we would show you what merger quests have emerged into staging that are not yet in production. That's a great marriage of these two views that you'd be able to see the diff between them. It seems this works better. I'm actually losing my voice, wow. Nobody, I don't have larynxitis. We'll see how long this lasts. So seeing which merger quests are there, you know, because you can already do a diff and you can look at the commits and you can look at the commit messages and stuff. But really this marries a couple of awesome needs of information like we think in terms of merger quests awesome. I look at functionality groups of functions and say, this feature has been shipped into staging but not yet in production. This list, although it's just a mock-up, it shows the exact same information, would show you maybe the last five things that were in production or what was included in the last deploy or whatever it is, whatever works best for your environment, maybe even because we don't deploy that often. So showing just what's in the last deploy might be enough but for people that deploy 17 times a day, maybe that's a little less useful and you just show a history. But then we also build in a little bit more of the operations kind of stuff and say, all right, what's the state of my pods? Here we're flagging one, we're error rate exceeded something, there's some alert that popped up and here we're showing this automatic rollback kind of stuff, whatever. But basically just really building in this ops view. Of course, this is still a dev ops view in the sense that I'm looking at an individual project and looking at all this stuff. So one permutation of that would be what would this look like for marrying that sort of the ops view of all the production where am I at or I'm looking at maybe a microservices kind of thing where there's five or 100 different projects and I want to really quickly see the status of all those. I think this one's got a mock up. It doesn't look as impressive, frankly, because I just become sort of a matrix of stuff. But from an ops perspective, this could be really valuable and it just really quickly gives me the status of staging production at least. They may care a little less about review apps from an ops perspective, but certainly being able to see really quickly what's the status of my production fleet, what's queued up to go into production, what hasn't been deployed yet, etc., etc. So those are some of the concrete ideas we have. I think, you know what, let's go through some of these other ones because there's some other cool ones in here too. It's all future stuff. This in particular is unplanned. This one doesn't have, by the way, does have mock-ups down here. Let's go to the last mock-up. So here the idea is that you've deployed something in production and some module or whatever that you depend on has been updated, not by you but by the community or whatever. And so we would automatically, so there's multiple levels to think about this, sort of the easiest and most naive way is to say, on the next merge request or next CI CD run, we would go and check to see if you're testing something, to see if anything's outdated. And we might fail your CI CD and say, oh, you've got an outdated version of, in this case ES6 promise. And maybe that wouldn't be a fail normally, but let's say it was a security release. Maybe like, oh, well, let's fail that because you haven't updated. That's kind of lame because it's like, wait a minute, I'm working on something unrelated to this thing. Now you're going to fail me because something changed outside my control. That doesn't make any sense. Wouldn't it make much more sense to just run this stuff automatically? And even if, for example, nobody pushes for seven days, in the middle of that, there's a security release of something. You should just proactively run stuff and notify me. So that's sort of a second iteration of thinking about how you would notify somebody and tell them, oh, you know, you've got a security change. You should go and do something about it. But then it's like, all right, now the third iteration is like, well, what would you do with that information? You'd go and maybe give it to your junior developer to go and make the change and point to the new version, you know, like this, you know, literally it's, oh, you know, change the Semver, bump it up to the next model version. And then, of course, you need to test that that works. So you're going to create an emergency request. And then test to make sure that it still functions properly. But like, well, why notify somebody and tell, you know, your junior developer to go and do this? Why don't we just do it for you? Why don't we just go and submit this merge request for you and then tell you what the results are? In fact, let's go further and say, hey, it passed. We just deployed into production for you. Like, why would you have, you know, a security vulnerability in place at all? You know, so this goes from sort of the alert kind of mindset to you go to work in the morning and you just get an email saying, like, oh, production has been updated for the security release. And so even when these really huge like open SSL security problems kick in and everybody's got a frantically scrambled to fix it, like, why don't we just fix that for you? And of course, because you trust your CI, it would automatically deploy to production. And if it didn't, then you'd finally get the alert, you know, so instead of having an alert about 100 projects or microservices on all me to get updated, you just get alert about three of them to fail, that actually have some weird dependency that it didn't work on. And then you can actually focus on, you know, real problems. So that's sort of a glimpse at how we're thinking about this. This would definitely be an enterprise level feature. And again, it refreshed out some ideas, but it's unscheduled, but does really tie into the ops mindset. And I don't know if this has much, I think this is just talking about how we'd auto revert something. We've got a quick question. Sure. You mentioned that that that sort of automation would be definitely like an enterprise edition feature. Can you can you talk a little bit more about why like a smaller development team like under 100 developers wouldn't get value out of? So this is where things got a little tricky, because yeah, of course, smaller developer teams would get value out of that too. Everybody would get value out of that. Some of it has to do with sort of proportionality or whatever. One test I like to use is is there's some other way you can achieve the same thing using workarounds or whatever. And we're just making it easier. And that's a good case here. Like you can already do this. You could clearly manually do all this stuff. We're going to automate it. And automation is something that affects larger companies a lot more because they've got hundreds of projects with thousands of developers or whatever it is, and they just can't deal with the scale or it's worth dealing with the automation. But if you've got a small developer with a single project, like you're pretty much on top of it and if something changes, like yeah, you just go ahead and you're aware of it. The bigger challenges are when you're just not aware of how this thing might affect one project somewhere that you've almost forgotten about or whatever. The other thing is that, well, I don't know, just to be blunt, that I think our concepts that Enterprise Edition is only for if you've got more than X people is a little flawed. Instead, it applies more to those companies that those people value it more, whether they'd be willing to pay for it more, however you judge your value there. Clearly, small companies would value all this automation and everything else, but they're not going to get as much incremental value out of it as electric computer would. The other way to look at it is just that this is pretty advanced stuff, and frankly, it just doesn't deserve to be free open source. It's probably really complicated stuff that we're going to have to do there. Maybe there'd be levels to it. There'd be a version that says, yeah, you'll get an alert. We'll run this test once a day, or maybe we can just have a blog post about how to do this. You set up a recurring scheduled pipeline job that once a day tests to see if any of your dependencies have been updated. You could do that today, and then it would alert you. But to automate it, to actually create the merge request for you and everything else, well, that's in the Enterprise feature. It's not that version checking isn't important for everybody, but the automation around it really, really matters for a lot of things. Does that make sense? Yeah. I mean, I think the first way you described it, and that like, yeah, everyone gets some value out of a feature like this, but the overwhelming kind of value and use for this is in kind of larger development teams, like that resonated. Okay. So then this is just a feature showing how we're thinking about, we've got this canary deploy, and we have another feature we're not currently working on our schedule, but it's incremental rollout, so that it would not just roll out to a single canary or a bucket of canaries, but it would just slowly increment and go to 1% and 5% and 25%, whatever it is, increment your stuff. But let's say at some point, during that rollout, you detect an error. So this is a mock-up of what it would look like and be like, oh, error rate increased by something above our threshold. Let's revert that one, go back and create an issue or whatever it is, alert somebody to take a look at it. Lately, I'm thinking, I don't know, I really want to automatically roll back versus just stop it in its canary form and say, well, it's canary, let's let the canary be there so you can debug the canary, but just don't let the canary go on further. Because sometimes, error rate exceeding is a pretty tough one, but let's say memory bumps up, and you might be like, yeah, we added something and it's using more memory and we're okay with that. Don't stop my deploy just because it's using more memory, but there might need to be human intervention in that. But anyway, but somewhere along this line, automating a lot of this deploy stuff, pretty cool. I think I already talked about this, but basically, yeah, there's no visuals, but just not just showing the status of the deploy, but setting status of each part. So that's it for that ops feature stuff. But then there's another meta issue for um I did not come up. Let's see if I can get to it through there. Nope. It's in the C. Yeah, I guess it's in the C, but okay. So these the um the uh, there's a bunch of big ideas that I think are left, you know, from the I2P scope. And most of them are related to DevOps. Onboarding and adoption. There's just a whole bunch of areas there of it's actually a really big issue with lots of stuff just really show quickly show you the list of things. Lots of different ideas for how to improve onboarding, how to get people actually using idea to production, improving auto deploy, whatever. Not a lot of visuals. I won't really talk about it, but it's definitely one of our top areas. The next most important thing we're working on. Cloud development is this idea that you know, setting up your local host machine is actually kind of a pain. Um, sometimes if you switch between especially with micro services where like each service could be in their own language, whatever, like you don't have to want to maintain like Java and Ruby and Node and all these other versions of dependencies and every time something switches, you got to reinstall a new version of stuff or or whatever. You know, even just these days, it's developing on an iPad and they don't have a local host to compile things. Um, cloud nine is sort of the biggest well-known thing from an IDE perspective and Amazon bought them a little while ago. But even aside from the IDE portion of it is just being able to develop in the cloud and being able to make some changes and then push them back, you know, commit them to a repo. And we sort of have a little bit of a demo like this right now with our web terminal. So if you're on Kubernetes with this terminal button and it just pops up a terminal right in, I'll show you that if you haven't seen it. Yeah, here. So on the staging app, I just popped up terminal and I'm in the staging server and I could actually go ahead and, you know, edit a file there and I'll show you all the way through. So and I just made a live change into my staging app. And generally speaking, I would not actually recommend you do that because I'm messing with my staging app. That's not what this is for. Makes an awesome little demo, but it's, you know, it's not what you should do. What we want to do is come up with a way where people could do that, but have it be not on your staging app, but in maybe a cloud environment or dev environment that is specifically for this purpose. But that also lets after you make your changes and test them and run them live, you can then go and commit them back to version control and close that loop. So there's a whole bunch of issues related to that. And, you know, to be honest, it was what we were hoping that coding with a K would have provided for us and we have, you know, an integration with them, but it hasn't worked out nearly the way we had hoped. And so we're looking at, you know, alternatives and we think we can probably do this ourselves. Anyway, that's a big thing to flesh out. Ops features I just talked about. That's another big area of DevOps. There's several more here. We're going really quickly. Get out of paths. This is basically the idea that, you know, at some point, like Heroku is awesome because it gives you this really great platform that's easy to use and gives you all this functionality on top of Amazon and makes it, you know, and five or six years ago, it was like super like brain melting, you know, awesome to get people to do ops and do ops. So as a developer, I don't have to be aware of how do you even do ops? Like, Ruby just does the ops for us. And the idea here is that, like, you know, we've got a lot of these components and we're not going to invent them all from scratch. We're going to rely on Kubernetes, for example. But on top of communities, we could make an awesome environment, an awesome ops environment or a platform as a service. And so there's an issue there to discuss, you know, what it would take to do that. I don't bold with it because what I've done here is these three are the things that I want to work on a vision for right now. But just at some point in time, this is a big item for us, you know, if we can make it super really easy for you to, you know, just really fully manage your ops environment via GitLab and maybe like, for example, never touch the Kubernetes dashboard, never touch any of the tools, just use GitLab tools to do this. That's pretty powerful. Sort of related is actually an idea that's in the onboarding stuff. But the idea that, like on GitLab.com, we can actually provide you a Kubernetes cluster, or maybe a shared cluster. You have to worry about security and this kind of thing. But imagine if you're a brand new user on GitLab.com, and you push up an app, and you have nothing in there specifically for GitLab, you just push up your code, and we're like, oh, that's a Ruby app. Okay, I know how to build up Ruby apps. Oh, and I also know how to test Ruby apps. I'm just going to go and test them automatically for you. And oh, by the way, I know how to deploy this. I'm just going to deploy this to production. And we'll make a production dot, your project name dot, you know, ephemeral, GitLab apps.com, whatever the hell, some domain so that it's not going to affect actual production. But if you wanted to, you would just point your DNS over to this production app, and you've got your production app running on GitLab infrastructure. And that's really what Peroku provided, right? But that also is an onboarding thing, that we just make it really easy. Because if we want everybody to have CI, well, let's just turn it on for you. That's pretty awesome. But if we want everybody to have CD, we can't just turn it on for you because you have to have a place to deploy it too. So if we just provided you a Kubernetes cluster, everybody gets a cluster, then you just got a place. Now, maybe we'll severely limit it. We'll make it limited in some way so that you're not going to run your production stuff for long there. Or if you do, you have to pay for it, whatever. But we're not going to try and make money off of the production resources. We want to make money off of making it really easy. So really, what we want to do is encourage you to then go and spin up your own Kubernetes cluster, ideally on, say, Google, and we'll make a nice little link that says go and spin up a cluster on GKE We'll make that really, really easy. But to make it super easy for a first, you know, for some number of days, we could just provide you that cluster automatically. Anyway, so auto DevOps, we're going to talk about in a bit, so I'm going to jump over future flags. We just talked about briefly. I feel like I might have talked about them last time. So I'm not going to go into too much detail, but just they're really about decoupling delivery from deployment. The idea is you make your code, you deploy it, but you haven't turned it on. So it's not delivered yet. And the idea there is that it means you can merge in the mainline more often because it's not affecting anybody. But it also really helps because you can do things like, when I do deliver, I can deliver it for certain people, like just get lab employees or just the beta groups or whatever. And then I can control that. So then if the error rate spike or whatever, like, well, it's just a few people, I know who they are, they're going to complain to me, it's not a big deal. But I can test things out, get it polished, fix the problems before rolling it out. And then you can also do things like roll it out to 10% of the people, 50% of the people, whatever. It's all about sort of reducing risk, improving quality, and fundamentally by getting things into your mainline quicker. So it's ops-ish in that sense. It's really still pretty fully on dev. Version checker I just showed you, artifact management, this has become a hot topic lately. We already have a container registry for docker image artifacts. And we also have file-based artifacts that you can pass between jobs and pass between pipelines. And you can pass between cross-project pipelines soon. And we have ways to download that and browse them. But if those artifacts happen to be things like Maven or Ruby or Node modules that you want to then publish and release, and then consume in other pipelines, we don't have a formal way to do that. And you can obviously publish to the open source Ruby gems, for example. But if you want a private gem that is only consumed by your team, and Ruby developers maybe don't do that as much, but Java developers do that all the time. A lot of Java developers use Artifactory or SonarCube, whatever. And so anyway, in order to complete this toolchain thing, the idea is that we need to have some first-class support for that. Either by bundling in one of these other providers, or by just adding layers and APIs on top of our existing artifacts. So my personal pet favorite right now is we already have artifacts. But let's say you can just tag those and say, oh, this is a Maven type of artifact. And then we expose that via the API. And so then you can declare that in another project. And it would just consume the APIs and it would just know how to do that. But it would also use our built-in authentication. So you don't have to set up creds and do all this declaration. You can just be like, oh, I've got access to this project and this project so I can get the artifacts and I can just consume it all really easy. So those are the high-level things that I think are big ideas for DevOps. So let's talk about auto DevOps then. And this is actually really spanning from the near term to the very long term. But the idea here is that it's great that we do a lot of DevOps. Sure. And in a very simplistic way, it's like, oh, but shouldn't we just make this stuff automatic? The way I'd phrase it as we should provide best practices in an easy and default way. So the idea is like, you can, right now, you can set up a GLab CI YAML, but you have to actively go and do that. But really every project should be running some kind of CI. So why don't we just, again, detect when you've pushed up a product, project, sorry, and it's a certain kind of language. We'll just build it and we'll go and test it because we know what to do testing. And so today with auto deploy, we can already use auto build with build packs. So this, the link is actually to our production stuff. This works. We will automatically detect, I think, one of seven different languages and automatically build your Java app or your Ruby node. I forget what it may be. Go. I'm not sure which ones are in there. And we use Heroku's build packs actually to do this build. So we build that up. And then if, again, using auto deploy, we'll go ahead and deploy that. And so that's, again, pointing to actual documentation. This is a real thing. You still have to obviously have a communities cluster and do that. So it's not fully automated if you don't have that. But if you've got communities, like, hey, this is a one click, one click to do it. I can't really show you right now. But it's really easy. It's just literally one click. You pick from the menu. Oh, I'm on communities. And then pick submit and you've got auto deploy and auto build. One of the things we don't have is auto CI. And so that's a little annoying, but it's one of the things we want to pick up. And actually, hopefully, Dimitri, or CTO Dimitri, is going to pick that up in the Q3. And looking at using Heroku themselves actually extended build packs to do testing. And so that means that there's at least five build packs that know how to test these languages. And so like, hey, let's use that. Just automatically that. But even if that doesn't work, there's a lot of other things we can do. Other companies have all this stuff automated as well. So even if we can't use Heroku CI, being able to say, oh, this is this language, we know how to test this language, making that automatic. And then, again, either it's automatic is multiple levels of things. It's like, is it a wizard that configures this stuff for me? Is it a one click checkbox that says, yes, turn on auto CI? Or is it templates that I can easily add into my GitLab CI demo? I think in order to qualify auto, like, part of the idea here is that it shouldn't be templates, it shouldn't be blog posts that tell me how to do it. That's just CI. It should be like, literally just I pushed and it worked for most of you know, a checkbox or two. That's the idea is that all right, well, let's let's go further. What other things can we just automate here? And not automation for strictly the purposes of automation, but about bringing best practices to people. So you actually work hard to turn these things off. If you don't want CI, it's right off as opposed to like, yeah, by default, you should have this. So, you know, this is a really, really long list of things that, you know, when you think it's for everybody to get to the first ones have links because we're actually tracking, you know, more closely real, real issues for this, you know, auto metrics is a great one. Like, if you're running certain languages, we should just be able to, you know, really easily go and just pull the right information out of there. But, you know, whenever it goes on, the list is huge. But the idea is that we can build up this auto DevOps, even a marketing term and start talking about it in that way. And so not just say that GitLab is great for your DevOps and is a complete DevOps tool chain, but in fact, we do all this stuff for you automatically. There's a lot to be done, you know, to make this fully automated, you know, and what percentage of projects can we really do? Like auto deploy is a great example, like that only works for web apps. It's not a web app, we can't just deploy it. Like what would it mean we deploy it and like it just wouldn't function? You know, if you made a command line app or whatever, like what would deploying even mean? Or if it's again, like a Maven or really any kind of like module that you bundled up and released, like, well, that's not the same thing as deploy. So, you know, maybe we need an auto release, it's not on this list, but maybe it should be. But within the web app space, we can do some of this stuff automatically. So, that's it. Everything you ever wanted to know about DevOps. Questions? None on my end. It's a lot to take in. I don't have to master it all right now. Mark, do you have like, so looking at this list on auto DevOps, I know you talked about, you know, some of them are sort of in process or in sort of thinking about designing, you know, do you have sort of a master plan in your mind is to sort of, you know, when this all gets built out and added into the platform? It's a good question. I think that the onboarding stuff that I talked about is our next most important thing to work on, or the most important thing to work on next. And that will start touching on some of this auto DevOps stuff. Like, ideally, I think one of the best ways we could onboard somebody is to just give them CI. And again, maybe we can't do auto deploy because you don't have Kubernetes, but we've got shared runners for free. So, just turning on CI for every project, that would be pretty awesome. And so, if we just auto built an auto CI, that still might take a few months, but that would be great. If we go further and add Kubernetes or cluster built in or whatever, or just maybe we can't automatically give you a cluster, but we make it really easy for you to create a cluster. And then once you've got a cluster, we can then turn on the rest of auto deploy and auto metrics and everything else. That's all pretty medium term stuff. I did say that like cloud development, if I go back to, let's see how far back was it. Yeah, right here. Like, these are the three things that I want to work on, you know, basically in order. Maybe I'll actually swap that order, frankly, as I look at it. I think I want to work on ops features before I work on cloud development. I think that there's a lot to be said for going after the ops operator, the ops person. And so, you know, I think that that's a big chunk of stuff. And that would really make a big difference in fleshing out sort of the DevOps, not auto DevOps, but just really focusing on DevOps. The rest of these things there, I really don't know. I mean, some part of me feels like, oh my God, they're years away. And then some everybody says, well, when we decide to do them, we'll come up with something in a month, we'll ship it. Then three months later, we're going to have a pretty good version. So it really just kind of comes down to sort of what the priorities are. And it's too hard to play crystal ball on that. By the time we do these other things, that could be three or maybe six months of work, whatever. And even as I say that, part of me is like, well, we could do one month of work in each one of these things and then circle back around. And there's something to be said for that. But I just know that there's a bunch of stuff for the onboarding and then a bunch of stuff for the DevOps that could easily be a couple of releases each. So yeah, I would have said, for example, if you'd asked me that original diagram that I showed with the big scope, if you said, how long would that take? It's like a multi-year thing. I would have never predicted, frankly, that we would have shipped as much as we shipped in the year. And that's a testament to our velocity, but also to focus and really and really said having this massive, great vision of delivering all this stuff and really pushing hard to deliver sort of minimal viable changes for each of these things and then adding to it later and believing in the breadth. So now that we've identified that DevOps is part of our breadth and ops is part of our breadth, I just I can't see holding back and ops features to me seems like the logical next thing after onboarding. Mark, I had a question. I can't remember if it was you that mentioned it or if I shot someone else, but I thought we were going to have a license checker for open source software. And would you include that in this whole kind of macro, big ITP areas of focus? Yeah, I think so. I mean, I called it version checker because that's this issue actually is a flow that I wanted to demo out and it was very specific and it was about versions. I think license checker is a little different in that you don't need to sort of proactively go and check every hour to see if the licenses change because for that matter, if you bundled it up and it's got a license, that license is the license. So license checker is more like when you do a new merge request and you add new dependencies, are those dependencies valid licenses? That's where you'd want to check it. So it's more like just a job in your CI-CD pipeline that just checks for any new modules, if none, great. If there are new modules or new dependencies, then check the license of them. But to do it right, you don't necessarily want to do that manually in your job definition. So I could easily imagine wanting to automate some of this stuff or do periodically audit existing projects or things like that. So you'd want one big button that would say go and check all my projects to see if they're compliant. At any rate, it definitely is in the realm. It's less DevOps-y then in the sense, but it's not strictly about writing code and hosting it. Thanks. Joe, any questions? I think I'm good for the moment. Thank you. Appreciate the overview. It's great. All right, cool. So I want to reserve the right to come back to you shortly. Of course. Yeah, so one of the questions, sort of the immediate things we have is this auto DevOps and it actually shows up in our OKRs currently. So from a product and marketing perspective, is this the term we want to go with? Is this a big thing we want to push for? If you want to push for that, how much product work needs to rally around this? That may mean shuffling around our priorities a little bit to get to a core thing that we're comfortable calling auto DevOps. Clearly, I hope we don't have to have all of this before we call it auto DevOps, but if you say, oh, we've got the first five items, then that's enough to call auto DevOps, but the first four isn't, in which case, maybe that means we need to shuffle some priorities. I think things are actually lining up, though, because, again, Dmitri's going to pick up auto CI. So that's one of the big things, I think, from this perspective. But anyway, we need to sort of circle around and talk about whether we want to market it as such. If so, how does that translate to products? And is it a feature? Is it a product? Or is it a white paper? I don't know. Like, where does it fit? That sort of that macro issue is one of the top ones for me, because we also have a lot of terminology floating around, right? And so, like getting consistency around, how do we talk about these things? How are we messaging them? So not only auto DevOps, but all the different concepts that we have from conversational developments, idea of production, you know. And so, yeah, anyways, one of the first orders of business. So, yeah, got to figure out sort of how to tackle that, but expect to work closely with you as we sort of ideate around that. Cool. All right. Well, if there's nothing else, we have three more minutes back. Great. Thanks, Mark. Really appreciate it. Thanks, Mark. All right, yeah, no problem. Of course, we have any questions? We'll do. Thank you.