 Hello everyone and welcome to the general after you I'm proposing that I don't share my screen Because there's not a lot of context on the slides anyway The The things I talk about are in there. I first the engineering engagement survey And one comment there was I have a clear understanding of GitLab company objectives But I would also appreciate more Explanation on why company has objectives like this. For example, why is all the DevOps important? Even though it's almost impossible to get it right. This is very ambitious and a risky direction. I think that's an Awesome question as I'll try to answer that and I really appreciate people asking additional questions or Arguing with with what I'm saying So With GitLab we went from just version control to doing both dev and ops and What we're seeing in in the DevOps world is that There's an explosion of the amount of projects that companies have due to the rise of microservices and That for each project you need more and more tools It's no longer enough to just have some code under version control. No, you also need tests And you need to check the quality and you need to have a linter and you need to store your secrets and On and on and on There's so much things you need to run a successful project you need Running a project without monitoring and error logging and without measuring the response time in the client It doesn't make sense all these things should work And it can't What's happening now in the whole world is that people start a project and as it gets more popular they add more and more things but That's becoming less and less acceptable if you have an Application that consists of 10 microservices. It's not that you can say oh well Let's add logging as one of the microservices becomes bigger or when there's a problem No, when there's a problem you need the right information immediately you need the metrics you need to tracing you need to logging It's not like measuring response times is optional because a lack of response time in your microservice might might affect another Application or the another service or the application as a whole So you need to set up these these tens or the descents and tens of tools for every application That is just too much work. So with auto DevOps, we want to want to prevent that now Are we there yet? No, like auto DevOps Even the Mitri can't use it right now because it doesn't do database migrations. So we're gonna solve that Doesn't even do HTTPS automatically. So we're gonna solve that there will be lots of other things to solve But the end goal is to make sure that we can run get lab.com With auto DevOps, so all the different services that compose get lab.com should be deployable via auto DevOps And that's gonna take us a year to get there and maybe even more than a year I'm not sure it will be done by the end of 2019 What I do know is next year will have a couple of services on there like version. Okay, calm and other things We'll keep pushing to have more and more services on there and That is the future because Otherwise this this is what every company needs like in all the companies people are creating more services and it's just it's breaking down It's too much work. There's some reports that say that and enterprise companies some programmers are programming only four hours per week Not per day for hours per week. The rest is filled with meetings with with toil. We've seen companies where You have to There's there's like a Process to deploy something that's so long. It didn't fit on a a single wall Like it had to rep almost around the corner was 27 steps or some steps Consisted of seven different service now tickets That's that's what we have to solve. We're in a unique position to solve it because get lab is an opinionated Product an opinionated application. We have we know what you're deploying We know how it works. We know where the logging will be etc So we should we should help and that's why auto DevOps is important Ralph you want to verbalize your comment? Can certainly do that the explosion of project simply means that you you want to have pipelines for all of them But whoever set up a pipeline with kind of gluing all the tools together will have figured out that it's a complex Thing to accomplish and and therefore auto DevOps gets you from zero to at least one pipeline in almost no time So that's the value of it Yeah, there there will be customizations But over time it should be less and less and if you follow best practices even for complex apps like get labs You shouldn't need any still have ways to go like I'm super looking forward to Multi-project pipelines doing that better Brendan you want to verbalize your comment? Yeah, I just had a little Flashback not a positive flashback to you know the last job that I had I got hired to as the first kind of director of DevOps for a government contractor and For this federal government program that brought together three contractors and 15 unique apps There was like a like a 15 page word document on for each deploy You know copying this jar there moving this thing over there making sure this setting is correct So I was just saying that that is the real world and a problem that is not easy to solve But but one that we should I think it's ambitious of us, but important for us to be focused on solving Yeah, and and actually that the number of steps are just going up and up and up That the only thing we can do is automate the steps So make sure it's not humans not humans who have to check the metrics not humans who have to revert it that the complexity Will be there and then what we demand of apps is going is going up So so complexity will only keep going love the green screen by the way a nice pop-up one cool Another thing I care a lot about is the importance of velocity and Eric made a nice commit to the handbook which I which I love we We are unique in that we can Outshape the rest of the industry and that's our most important competitive advantage We're Open core so we can we can incorporate other people's contributions and not slow down But that will be a constant struggle as we add More and more teams like for example, we added a quality team and They've done Mac and team has done a great job like get a lot of the comics so much more reliable The application as a whole has so much higher quality But frequently the burden is on the developer shipping new features to make sure that they pass all the gates so as We grow it's very natural for companies to slow down to get focused more and all these other things that we also have to do so a Thing I'll keep doing and product will keep doing and engineering will keep doing is keep pressing on the importance of velocity and Finding what the bottlenecks are and solving them and It's important because I've seen a company slow down if companies Really reduce their shipping rate. It's almost impossible to get back up again It's what we're doing now is almost a natural natural thing is to slow down and if you go back to a natural state of everyone Doing too big of a things not iterating not shipping frequently the natural state will be That and it will be it will be very hard to get run back up again So that's why we never have like a book fixing release because if you lose that pressure for to to To move people ahead to ship new things it it will never come back and you'll stay at that stage for the for the rest of your company John had a comment. I think it's about the previous thing, but John. Want to chime in John may said Just want to say that, you know, we're starting to see this this impact. Yes, it's getting crazier, but you know, one of our one of our customers Just said the other day and they're presenting on this in Atlanta for us But they were talking about how they use GitLab to just make all that chaos go away and Automate things and now they're actually moving things to to conversational development They've kind of gone away from what Jira's doing and they're bringing everything to the merge request because things move so fast inside GitLab, but they that's the point where people come together. So what you talked about Really about a year and a half two years ago about conversational development was right on because that's exactly what people are seeing It's a paradigm shift on how they process things I have another customer that very very large Customer said, hey, we went from two week releases to six times a day now. We're on a mission and go to 20 minute That is what conversational development is all about and making customers do that Only way you can do that is to simplify and we're doing that. Well, so good job. We're getting there. Great job team Awesome. Yeah, and I think I think with concurrent DevOps, although it's new to us and it doesn't feel comfy yet I think we'll see that we're spot-on about people Not not We can't afford to just hand it over over like a baton people have to work or currently and I think I think we'll see over time that that That that message will start resonating Joshua, you want to verbalize it? Yeah, sure. I was just gonna share some experience on my last company actually where We were pretty successful. We had a user base grow We were shipping pretty fast but as we grew as a user base grew we we heard the feedback as GitLab does that things are sort of breaking here and there and You know, maybe consider taking a longer time to Ship things and take more care And you know, I think the easy answer is just to say yes and maybe slow things down have longer cycles more testing And the harder answer is to really look and see, you know How you can address those concerns about losing your velocity and what you need to do to invest in the process and the automation but you know, we slowed down and It was it was really not fun and we and that ball just keeps on rolling and it's so hard to try and to try and recover So there's always like a rash totally rational reasons to go slower But it really needs to end take a hard look and invest and Figure out how you can avoid doing that while still meeting the other obviously customer goals you have So, yeah, just thought I was sure that might Thanks, Josh and look it's From the start of GitLab the very start we people argue that we should have a two-monthly release cycle But I'll never double never have a ship as much as we do now So the shorter we can get things the better and sometimes it's really encouraging to see a conversation For example, we had a conversation about feature flags and at one point it was going In my opinion the wrong way where every new feature would need to be a feature flag That would mean that first ever release with a feature flag in it and then the next release you deploy it And then you remove the feature flag. It's a lot of extra overhead for every feature we ship So that was meant slowing down, which is not great We should have feature flags, but only for things that are likely to break Then we Started thinking a bit more about it and someone proposed And feature flags can be used to ship things after our merge request window or after our merge window after the 7th or the 8th When we're no longer merging a feature flag can be used to Ship something that you're not totally sure about But with feature flags, you can at least turn it off if it's needed So instead of going slower, we would be able to go faster and I think that was a great great turnaround There's a comment from Lucas. You want to verbalize your question Lucas? Yeah, I mean there was an exciting announcement by sourcecraft that they're open sourcing their software So I wanted to ask when we are going to incorporate source graph into GitLab or But it seems like I have to read up on hack on news and read your comments and the comments of source graph CEO Yeah, yeah Source graph just announced they're open sourcing it Source graph is a code navigation tool So it looks into wholly the abstract sent X tree of the code understands the code and allows you to navigate between it and It's the there's a couple of startups that do this I think source graph is the best product on the market right now as far as I can tell And they have an a protocol a language server protocol that I think they contributed to Which allows you to plug it in anywhere? I Think it's really an amazing product. I think it's great that the open source it It's great that they choose the Apache license instead of like a GPL and going for a dual licensing strategy This means that we can ship it as part of GitLab and I think It will make product developers more productive There's a monocoe plug-in for it. So we can add it to the web IDE I think the really interesting thing is to add it also to our code navigation. So when you Navigate to a repo you look at a file that all these These pop-ups are available People that I've talked to to that use for example browser plugins to achieve the same effect where most of them were enthusiastic about it So it seems that it's a big value add and it's amazing that they're open sourcing all this This value. So I think it should be something that we Have in every version of GitLab for everyone and it will make a huge difference I'm really excited about that apart from that the CEO Quinn is also a great person and and I If I squint between my eyes a bit, I think I detect a few inspirations That that GitLab gave them to to do this and I Think it's it's it's great. It's it might be the power of open source that gets their product more distribution this way Very excited for this Cool slide five is about ubiquitous language You'll see me talking Frequently when you see me Arguing for something it might be that I want to want to standardize on terms. I want to define terms and That's because as a company goes communication gets harder. There's more concepts in the organization floating around And the hard thing is just understanding each other when you have One word that means multiple things is going to generate confusion And when you have really long words that explain things people are going to use part of that explanation a part of those multiple words and then not have something clearly defined and I've seen it and it's super wasteful. It's unnecessary. So as a As as our management and leadership, we got to make sure that we have ubiquitous language that things have a definition that's clear that is mutually exclusive that is comprehensive and Many times you'll you'll see me either trying to make search a definition or try to enforce it and sometimes it's Things but you can argue how important is it what's the difference between a team and a group and a company and get labbers I think it's important to have those things straight that when you talk about your team It's always clear. It's the team where you belong to with a common With a common manager and that we talk about a group It's something else can be a stage group can be a director group, etc When we talk about get labbers, it's people all the people at the company Talk about the wider communities to people not working at the company, but part of the get lab community, etc Number six is Why if something is in the handbook is When you change it you go to handbook first, but before that James has a remark James on a verbalize it Yeah, I was just saying there is a cost to these well-defined words But when there's a more general word you can say oh, yeah, my team was doing this You can have a conversation where you're thinking about something else The well-defined words mean you have to kind of stop and say my function was doing this and kind of interrupt interrupt yourself to use a specific word, so I'm kind of I kind of dislike these and I'm the same with grammar though So I'm probably not everyone like I prefer it when there isn't a rule You could just say what communicates most clearly rather than most precisely Yep. Oh, that's it. That's a good point. It's it's and it's it's accurate For example with teams and groups. I think we tried something else be first and it was so unnatural that Martin Said look I tried this and it's not working So I'm very sensitive to that if people actually tried something and it's not working great. Let's change it Maybe team is one of those things where we should not Try to just pin it down because it's a general word But in that case we just retire it from our from our official vocabulary and every time you use team people know it's ambiguous and it can mean anything and But then group is defined and then we need to find another word for team I really tried to do that. I couldn't find one So if you have one great, I'm open to changing it So you can use team for freely and that's some some of the words We just kind of give up on like they're they're so ambiguous when I forget the definition, right? And about like the brain damage you kind of incur while trying to think about these definitions It becomes more important as the company goes because every piece of communication will reach a bigger audience. So As the company gets bigger there's more of a burden on you as a writer to make sure you clearly express your thoughts If you're with a group of seven people Yeah, the burden should be both on the writer and the reader as the company gets bigger should be bigger and a communication is Wrapped by like a hundred people a thousand people There's more burden on the writer to clearly express their thoughts So it's different if you're calling with one person I'll care less about the definitions If it's a team call you're addressing the entire company There'd be more enforcement of the definitions If games if you want to respond then feel free Yeah Yeah, that makes perfect sense. And especially the thing about being more flexible and smaller groups Yep, and feel free to call me out on that like Sid this is a small group don't don't be I Don't focus on that too much numbers slide number seven Atlassian's new terms they forbid benchmarking Apparently Atlassian doesn't like when people benchmark their tools and publish about it I don't think this should be Gitlabs policy We like people benchmarking and I encourage people to read that hacker news thread because there's some some great Information about how people perceive Atlassian's products and in that in that friend and Jamie was kind enough to on Monday immediately change our terms and we now explicitly allow benchmarking which I think probably makes us the first company in the world to do that It wasn't wasn't needed strictly, but we wanted to make a point and Go ahead she's I Know we are going to tweet about it I saw your slack, but I think we should think about how to get that word out even stronger It's a differentiator from other companies from a marketing perspective I'm happy to discuss that, but I think everybody should retweet The tweet that'll go out on the benchmarking ability But I think we need to look a little bit more. How do we spread this word a little bit wider? Well She's it's called everyone can contribute so for free to write a blog post all the materials is there all the links are there So just just get a blog post out the tweet is here. It's already went out 19 hours ago Quick suggestion on this. Do we also want to just request that people publish those and how they did them So one of the things that always comes up with benchmarking is what you did and how you did it So not that it's required, but perhaps we ask hey If you benchmark, please make sure you publish how it's how you Replicate this right like please please give these details so that everyone else can follow up with you Some I doubt we'd get anyone playing that game necessarily with us, but that's historically always an issue around benchmarking So it might be worth us just being clear on that if we can yeah I think that's valid. It's I think it's like security Vulnerabilities like you can disclose them without giving us notice. It's your legal rights to do so But please don't please give us notice so we can we can prepare Mitigation for for for everyone else. I think it's the same here. I think Since this is a confusing situation I think right now saying we would prefer if you publish how to reproduce your results I think that would lead to confusion and these these things are confusing For example, the first iteration of game. He was to forbid benchmarking because that's what people naturally do so I think in order to have Clear communicate like a clear statement about this is just to allow it and not to put the burden on anyone If we see a proliferation of benchmarking that is not reproducible We can always say hey great if you publish benchmarks, you're not required to but please do make them reproducible. I do think in In programming and developer tools people tend to be way better about this than in some other branches of Software that I've seen benchmarking like there's a lot of smoke and mirrors in I don't know database benchmarks or stuff like that, but I think that I Think it's getting to a point where you have to have a reproducible test suite and Things like the call me maybe series about databases like the reproducibility of that is just amazing and I Think that you almost look a bit silly if you have a benchmark that doesn't reproduce and people will call you out So I don't think I don't think we have to say that. I think we just say hey, we do allow benchmarking and publishing them I'll pull churned in with quick versus quirky if you've renamed the binary and It ran different things like that and and benchmarking so far hasn't been a problem for us every time There hasn't been a lot of benchmarks and every time someone found something like we should just improve it I can tell you right now what get lab is not doing, right? We use too much memory. We should go Gently should not load the complete reels in the word solving than a giddly one-to-one We need a multi-threaded application service. So we don't consume that much memory However our response timings like the timing of a request are greatly improved especially around merge requests because that's now No longer all server dependent It's a proper view app and those timings are weighed down like first paint and things like that are much much better than a year ago Which is very important number eight Yeah, it was just a fun thing. I saw Chaos engineering or failure injection testing seems to be taking off. I think it's another thing that It's kind of hard to set up unless you would use auto devops in which case we can do a lot to make it work out of the box We're 27 minutes. I thought this was really fun I think this general after you was an example of everyone can contribute things everyone for leaving comments and then Speaking speaking up when asked to verbalize them appreciate that I'm glad to see it doesn't lead to a reduction in the people commenting in the chat So, thank you very much. Have a great day. Bye