 So I'm just gonna start with a fun story because I've had a long day and I'm tired. We're in a nightclub right now. Like let's think about that. This is my first time in a conference in a nightclub. Also first time at a conference in a nightclub that I've danced at. So that's a fun little thing that's got me just like, I never thought I'd be on this stage giving a presentation about DevOps, the times that I danced here. So I want us to think about this idea of how all remote enables DevOps. What that means and we're gonna explore that a bit. We have a couple of questions that I need to answer when I talk to you and hopefully I do a good job of that. I'm gonna start with me. Now you may have seen me earlier today as an emcee. I appreciate John emceeing me as an emcee earlier. I can appreciate that. I spend my days not emceeing but I spend my days as a support engineer at GitLab which is a really wonderful group that I'm really proud of because we really do engineering. I think support is an often overlooked part of organizations and I truly believe that support engineering is something that will make organizations successful. Now I wanna take a minute as well to just highlight my career just to give you more perspective and the things there, Linode. This was a small company that was very anti remote. I spent my time there about employee number 11 to about 50, super anti remote. Going to a smaller startup, three to 11 people. Remote friendly, joining GitLab at about 100 people growing to where we are now today, about 10 fold. Fully remote. So it's been interesting to see that in my career and to ask questions about what works, what doesn't, how it's working. I'm also known for wearing many literal hats. So when it comes to all remote, I wanna talk about that as an interesting idea because I think some things around all remote are fascinating. And the first thing that comes to my mind when I think about all remote is this idea that remote is not new. And you're like, okay, what does that mean? And what I'm saying that, when I say remote is not new, if you have two office buildings, they are remote to each other, right? That's actually true. People working in office A and people working in office B that is remote to one another. And that's not a new thing that's happened in multinational corporations for many, many years. And that silo effect exists, something we know. When you go all remote by nature, you now have a silo effect that is every person is potentially their own silo, which is fascinating, right? That is the subtle difference. But in an office, we kind of pretend like that can't happen. I don't know why, right? You could still silo yourself away in an office. You could still detract and not get involved. You could still misinformation. The office space itself does not guarantee that's gonna work. And all remote does not guarantee that either. I think that's really interesting. The two really key things that I wanna drive home today that I think GitLab has taught me, setting values and specifically our values around transparency and collaboration are what really enable us to deliver DevOps, right? You can take that to your organization whether you're all remote or not. So that's very exciting. The pictures you see here are for some of my travels in my time all remote. I figured I'd add them for some fun zest. First one, a road trip across America in 2016 on a whim. The second one, Cape Town. The third one, visiting family in Alabama, Amsterdam and Copenhagen, which was just ability to be all remote has allowed my life to be amazing and do amazing things. But really transparency and collaboration are what drives success at GitLab. Now, thinking on that, we wanna think about what does DevOps mean? And we think about the keynotes earlier this morning and this idea of DevOps and cloud native journey. How many times today have I heard cloud native journey? And we wanna think about DevOps. And for me, the idea, we won't be able to read this, but I'll give you the gist here, hacker news. But the idea of DevOps is really that unifying glue. That's what I'm focusing on, right? The idea that DevOps is unifying two processes into one, whatever they mean for you. And we need to think about that, right? So when I'm talking about all remote and DevOps, I'm talking about that glue. So it's funny because this past week on hacker news, there was a thread talking about DevOps and the top comment was like, DevOps is a religion. Everybody's doing, you know, and I'm like, oh boy. And so I have this, if you check my slides out later, you can read this, but the one comment that I took out, the person right below in this thread said, you know, DevOps really means to me. I go into Slack in the pound DevOps channel and I see my build failed and I randomly click buttons until it either gets better or gets worse. That's DevOps. And I was like, wow. So that's real. That's true. That exists. Go find this thread on hacker news and that person has a very cynical look on it, but I think that it can be warranted, right? Now, when we're thinking about that, that kind of brings this to the forefront, transparency and collaboration. He, you know, that person feels jaded towards this and there's a chance that transparency and collaboration were not a part of that process. Now, I was fortunate enough to talk or and see Martin's talk in this room earlier today where he talked about the CE to EE merge, which is something I want to highlight and also I want to highlight GitLab.com deployments, which is something that Martin also talked about. It was exciting to see that this is such a topic that we're able to leverage how we've transitioned at GitLab. Now, my time at GitLab, when I started and Martin highlighted this as well, we needed to merge CE to EE, which was a manual process, which is insane to think about, right? We were doing this up until recently. In 2017, we were manually merging two things to ship them and that just is not scalable. And that's not DevOps. And that's something that I want us to think about, right? As my talk is all remote enables DevOps, this is not DevOps. We're all remote, but it's fragile. And this is something that we want to think about as we're enabling DevOps in our organizations. So then we start moving towards more automation, right? Martin's team and other groups, somebody else named Remy was heavily involved here, to deliver an automated way to merge CE and EE, which was amazing. That helped us free up a lot of time and energy to make things more efficient and make things more transparent and allow people to solve problems and not deal with toil. So now we have this idea where we're automating and we have less toil, but this is still not DevOps, right? I'm just focused on dev, which I think is interesting. We wanna think about gluing these things together, but at GitLab the experience has been still very dev ops, which we'll talk more about, but we're iterating. And I think that that's an important thing to think about because DevOps is a process that's going to happen and it's not just a one and done or we've done it. It is something that will forever be evolving as your needs and changes in your organization happen, right? So when I was building this slide deck, it was just a pipe dream that we would have a single code base that would just eliminate this class of problem that we were dealing with. They would just melt it away and allow us to be much more efficient, ultimately our dream goal. As of last week, Marn's team delivered that. We have a single code base, so all of that iteration, still on just this dev side, is helping us to get closer to DevOps. The collaboration, the transparency are what drove that home. So I was really excited to see, I don't know if you'll be able to read it, but in our Slack dark theme, if you could tell, really excited to see how excited many Git labbers were. Also you can see my emoji habits, so that was interesting. Really excited that the team is so just passionate about this idea that we have now made ourselves so much more efficient. It's much easier to contribute and collaborate and that is something that we want to drive forward. So this is one half of our DevOps journey, right? But all on the dev side, interesting. Now I wanna think about deployinggitlab.com. If you were in the room earlier and you had a chance to hear Marn speak and talk about his time deploying Git lab, we had a release manager. If they were a physical person, pushing buttons, releasing to prod, this is a horrible process. This is not something that you want to do. We rotated it, it caused failure. It was something that was risky, right? This is something that is the opposite of a well oiled repeatable machine. So then we started building auto deploys, which is again, something that makes us get closer to that repeatability less toil and allowing our ops group to deliver Git lab. But again, in Git lab's DevOps journey, they're still very separate and we're trying to glue them together. And in the three years I've been here, we've inched our way closer, but I still don't think we're there. And I think that's exciting because all remote is enabling us to get closer. Transparency and collaboration are bringing us there, but it's still not a present day thing. So in that, one of the things I wanted to highlight that is I think unique to Git lab, we really envy sometimes the way that Amazon or developers can ship the product all the way out to the end as something that they're aiming for. And I think that's phenomenal. But at Git lab, we want to have a community and a community involved. And you'll hear from some of our community members later, which I think is wonderful. We can't build a process where somebody can, a dev can deploy because they're not a Git lab or they don't work at Git lab. They're just a community member, which we encourage, but that's can't be our process. So we're trying to make how do we build dev ops at Git lab and do it all remotely? So with that, I want you to think about in your organization, in what you do, the idea of where is transparency and where is collaboration? Because you're trying to fuse two things together that sometimes have been at odds. Hopefully they work well together. And if you think about that at the core, that is what's gonna drive your success. It's not Kubernetes, it's not adopting GCP, it's not these other things. We have to figure out as groups how we're gonna work together and build those groups together because that is gonna drive your success. So the last thing I'll say, I don't think all remote will fix this. And I think that there are orgs that could be all remote that don't see this happening, but the values that we have at Git lab really helped make this clear to me that that was the power and how all remote can enable dev ops. So thank you for your time. Thank you for listening to me. This is a lightning talk, so I wanted to get you with a quick hitter. I'm not gonna waste any more time. Hi, everyone. Oh, thank you. So this is a short story about some of the after effects of contributing to Open Source and specifically to the Git lab project. And collaborating online with a fast-paced team that's a Git lab team that ships monthly the product. I'm George. I'm a UX engineer based in Athens, Greece. I'm also a core team member at Git lab. At work, I lead the further engineering and UX design efforts and also recently introduced, oops, sorry about that, recently introduced continuous degradation and continuous delivery initiatives across multiple cross functional teams. And at Git lab, I participate in discussions around the triage operations, collaborating with the community and picking up stale merge requests or mentoring and coaching community contributors. I also review front end and UX changes whenever I can. And during the last six months or so, I have focusing on the design system behind Git lab, that is Pajamas, which we'll talk about later on. So here's how all this started. And I started about one and a year, half ago, started contributing. It was interesting because at that time, I had a little experience with most of the technology stack behind the product, including SAS, Hamilton blades, Ruby on Rails, RSpec and more. I started contributing small bits and bytes. So during the first time, the first months, I had to reverse engineer most of the code that was rendered on the browser of the app. I picked up from the engineering issues and every time I run into an open issue, I was wondering, I kept asking myself, can I pick this up and I make it through the finish line and does it sound interesting? So this led to getting from zero to one, I mean, learning a lot about front-end engineering and styling guides and testing styling, testing standards. This was also done in a production grade application that is GitLab, which is really interesting. It's worth noting that during that time, that the first months of contributions, I was almost half of my contributions. I wasn't sure if they were going to make it through the finish line because I didn't know much of the technology stack. And one notable contribution during that time is that maybe you've seen it, including private contributions on your profile. It was a still community contribution that I picked up and completed it. So I'm doing this for a few months and in parallel, the view team has picked up the view framework and progressively adopts a view across the application. I had very little experience with view during that time. I switched my focus to view components and during these months, I've improved a few view components and view-related changes. And every time I ran into a major quest from the front-end team, I took a step back and read the code review comments and remarks, suggestions. And this is how I got into view. Almost everything I know from view is mostly from reading code reviews and major quests from the front-end team at GitLab. It's quite powerful. I mean, reading other people's codes, you can learn a lot and especially when it's a talented team like GitLab. So from the first major quest, it was quite obvious for me that I was about to enter a very welcoming community, which is really important for new contributors. You can actually see the GitLab values embodied in every small interaction when the team members engage with the community members. And this was actually quite, as they say, what goes around, come around. I mean, receiving so much support during your community contributions led to actually improving collaboration with at-your-day work and at-your-work flows. So on the way, you have to keep some balance because when you start contributing and having a globally distributed team like GitLab, you start bringing people around the world. So I did this when I started, so just to balance my request between the front-end team and UX team, which eventually led to burnout. So as you can see, the top one is during the first month I contributed to GitLab, which is contributing during weekends and now, while a bit more intense, it's quite obvious that I skip weekends and also take regular breaks, which also helps. So for the GitLab team, working as synchronous and remotely is okay because the team knows how to work properly. So when you start contributing, maybe it's best to just ping members near your time zone. This will help not being always around and trying to respond to community code reviews, suggestions from the team members. So after a few months, I run into the design system, which is actually in the intersection between the UX and the front-end department. Based on view, we are building reusable view components. And having this in mind and how much I really enjoy this, I just dive into component and design implementation in various stages of the component progress. And I was curious at first how this works, how this can enable developer productivity and how teams can ship faster features and work more effectively. As a matter of fact, the design system actually currently powers more than 400 user interface components in the product itself. So it was really fun and I really enjoyed being part of this and helping scaling the design system and utilizing components within the product development life cycle while keeping in eye the work being done in the other stages of the product. And the last one is about the engineering workflow. So GitLab has a handbook. The handbook is open to everyone. So you can actually see how GitLab runs and how the engineering teams work and collaborate with each other. So having access to this was actually tempting for me to try this at my day job or for a side project with friends. These are actually issues and magic requests from a side project I picked up with a friend. We did a sprint for 30 days and we actually collaborated with magic requests and code reviews. And this led to actually trying this with your own workflows. I mean, certainly adopting similar practices takes a lot of time. It's mostly mindset change. The team has to adopt the new style of working and it took months at my work to actually adopt some of these approaches using project management, issue tracking and more. For me, it's quite clear that this way is the new way of continuously building and deploying applications. One interesting fact here is that the side project you watched earlier is a project that on launch day, on day one, running NPM modded had resulted in 400 vulnerabilities, 30 high critical vulnerabilities. So the secure software development lifecycle is an interesting part that you should take into account. I mean, if you're not used to having security in every step of the development. And this is more or less as... Thank you. Thanks so much for the coveted last spot of the day. How are we doing? So now that we're all a little bit more energized that we were a minute ago, I'm going to dive into my talk. Today's talk is called Deploying Your First DVT Project with GitLab CI. The original plan is that I was going to stand up here and live code it. And then everyone I told that to was like, wait, really? And so I chickened out. So we're not going to live code it. But I took GIFs of me live coding it, which is basically the same thing. So first a little bit about me. So my name is Emily Sherio. I was the first data analyst at GitLab. And I've kind of built a career of being the first data person that a startup hires. I've been at GitLab for about a year and a half now. Today, the team is eight people. A couple months ago, I was promoted to data engineering role. And then now I'm in a slightly different role. But as of two weeks ago, I was a data engineer at GitLab. Today, I'm an internal strategy consultant. And the people who watched me give a practice of this slide say you have to have a fun fact on your about slide. So ask me what my one rep max squat is at the end. 190, which is a lot for a woman of my size. Thank you. Thank you. So first let's talk about what DBT is. So just give me a sense. Do you know what DBT is? The community manager. And some cool person up here. I want to talk to you later. Nice. So what is DBT? It is open source transformation tool. So once upon a time in the very abridged version of history here, the paradigm around data was that you used to have an ETL approach. Storing data was expensive. So you don't want to store data multiple times. You pulled it. You transformed it. You only stored what you needed. Today, that's no longer true. And so we use an ELT approach, extract, load, and then transform. The advantage here is that when you have the data in your warehouse, if your business logic changes, you don't need to redo your extraction and loading step. You can just update your transformation step. And DBT is the transformation step. So we say it's the T and ELT. And it lets you snapshot, transform, test, deploy, and document your data all in an open source tool. DBT requires analysts to use version control. So when your business logic changes, you can see exactly where that needs to be updated. You can see what previous versions of the analysis, what logic was baked into it. It also includes dimension testing but alerting on testing. So we have at GitLab a number of tests around data quality issues that are because of manual workflows and logging around jobs, productions, runs, et cetera. This kind of sounds a lot like a software development tool, doesn't it? Interesting. So then your transformed data is what your company uses for reporting your business intelligence tools or data science-based analyses. So we get started with our new DBT project first by installing it. And that's not on this slide. So on a Mac, brew install. On a Windows, here's how you install it. You get in your car, you go to the store, you buy a Mac. And then you brew install DBT. So once you've installed DBT, super easy, you can start a project with DBT and NIT project name. So here I've named my project EmilyDemo. In case you haven't noticed, yes, that is how Emily is spelled. We'll notice, if we look at this really quickly, that DBT puts out some really useful information about configuring your profile. The docs tell you exactly how to do this. At GitLab, we use Snowflake as our data warehouse. So we have a curl command that we use to help set up our analysts' computers when they join the team that actually installs, sets up their profile for them. And then they just update their username and password. So that's what's running here. Once you have set up your new project, you can either, if you join the data team at GitLab, you're going to get cloned our existing project. If you've set up your new projects with DBT and NIT, you always want to see what it ships with. And much like LS on the command line, DBT has a DBT list command. So here we can see exactly which model ship with the example project. And it's a really simple, I think the next slide shows. So the next slide will show what the model that ships with the example is. But it's just a select one, right? So the idea here is that you're getting to see what DBT does with its off-the-shelf example. There are a number of projects available online, though, including a really great demo project called Jaffle Shop, where you can see what it looks like. The other option is the GitLab data team, and I'll include a link at the end, are projects public, so you can see what that looks like. The cool thing about DBT is that it's based in select statements. So SQL that you write in this select way, everyone knows how to do it. And we come from this world where data analysts, maybe that's all they knew. And we're bringing them into this more technical way of working with version control and alerting and testing and logging, but we're letting them keep the language that's always known in love. So the other advantage of DBT, for a long time in software development, we talk about writing dry code, right? And SQL, when you're talking about, I don't know, how many customers have bought a thing, you might want to know the customers in different parts of the country that bought that thing, and you might break it down by state, right? So tell me how many people in New York bought it, and then tell me how many people in Georgia bought it. And when you think about what that looks like in a SQL query, it's the same except for the where clause, right? Where state is New York, or where state equals Georgia. And what that means is that when some logic in that SQL statement changes, you have to update it in two places. And what DBT lets you do is actually leverage GINJA to write dry SQL. So once you've built out your logic, you've done what you need to, you've stored this logic in code that's version controlled, you've added testing to it, you can materialize your new models, your new data models as views or tables. And that's what happens with the DBT run. Now the reason this GIF gets stopped in the middle is because the run took longer than the GIF could record. So this is what a successful DBT run looks like. It tells you exactly what ran, how long it ran for, and you can see that it completed successfully. Now I could have planted an error here, and it would have said past one, worn, whatever, etc., etc. There are different tiers of errors, warns and errors. Can you call them tiers of errors when one's an error and the other's not? Failures, tiers of failures, there's the word. And so this is a really cool way to let your data warehouse sometimes sort through the problems that comes with different data sources syncing. So you've built your DBT models, you're up and running now what? Well we need to deploy them, right? How many people sat in Marin's talk where he talked about what it was like to deploy GitLab? A couple people, cool, so much smaller scale. We need to deploy our DBT models, and what that is is some place where we're going to run DBT run, just like we just saw the GIF do locally on a machine. So you can deploy your DBT models with GitLab CI. Keep your orchestration right next to your code. This doesn't seem that foreign of an idea if you're coming from a software development flow, but for data teams this is revolutionary. With GitLab CI we now offer DAG support, so you can do a lot more than just deploy your DBT models. You can run some custom ETL, let that trigger the appropriate DBT run file, and then have your tests run as a result. It's really cool. Run pipelines with dependencies, that's what, for those who are unfamiliar for what DAGs are, it's directed a cyclical graph. Say that five times fast and I'll buy you a drink later. And you can ensure that your data is moving as quickly as possible. You don't need to wait for pipelines to trigger on a schedule if you're taking advantage of this. The other advantage here, much like software development again, we can run the same CI pipelines on our MRs as we do on our production instances. So an example of what that looks like Snowflake, which is a very popular data warehouse, it's what we use at GitLab, uses, they have a feature called zero copy clones, where you can copy your data warehouse and work on a clone instance of it. And this is what we do at GitLab, where we actually, when you make changes to the DBT models, we run those changes on a zero copy clone. So we're not deploying anything that we haven't seen exactly what its effects on the production instance is going to be. Again, not that revolutionary in the software development space, miraculous in the data space. So, oh, this did not project well, huh? Well, I'll tell you what you're looking at. So this here is your profiles.yaml. So if you're going to deploy your profile, your DBT project using GitLab CI, you need to take advantage of your CI variables. So what you have here is the profiles.yaml file that we configured way back in the beginning up as environment variables. And then what you have here is a GitLab CI file where you can see exactly how we're running DBT and what the commands we're using are and how we're telling DBT to find the right profiles.yaml file. I'm sorry that didn't. I should have taken this on a white background, might be. So then when you deploy DBT with GitLab CI, what you see is a screen that looks a lot like this where you are in the same place for your code as you are for your pipelines. No need to go check some other application or some janky UI you have to hold host on your own. The advantage to here, and this is just an added bonus, is that you get to deploy your DBT docs on GitLab pages. But Emily, what are DBT docs? I'm so glad you asked. So I mentioned that DBT ships with this great documentation functionality. This is what that looks like. On the left you'll see that there's a list of models. There are folders of lists of models. These are the different data sources that we use on the data team at GitLab. And each one of these models is documented. So you can understand exactly why the logic behind a certain model is what it is. And this is really useful because sometimes you build things when you joined the company a year and a half ago, and then someone tells you last week to go check on something and you're like, why did I do that? Now we actually don't allow code to be merged into our data project without it being tested and documented. Which is pretty cool. So can I go backwards? There we go. This is the actual scripts to deploy our DBT docs on GitLab pages. And I highlight this and all the other code that I've highlighted because, again, the GitLab data teams project is public. And all of these screenshots come from that. So if you have questions, I'm going to hang out afterwards. And I'm happy to answer them in a Q&A now. But if you want to see what this looks like in production, you can go see for yourself. So to recap, DBT is the transformation step in the ELT process. You can kick off a new project with DBT and NIC. Push just like the rest of your code. Update your profiles.yaml to use environment variables. Set up DBT run commands in your GitLab CI files. Bonus points for setting up DBT tests as well. And then you can deploy your docs with GitLab pages. Then you're up and running. So you can see more. gitlab.com slash gitlab-data slash analytics.