 Hello, everybody. How's it going? It's, like, what, 10 AM? Is that, like, early morning for some of you? It's early morning for me. All right, well, let's get started. Since I have only five minutes, I actually thought I had 10. So whoops, we'll do what we can. So I'm here to talk about continuous delivery with Kubernetes, the prequel. So as Jim said, I work at GitLab, and it sounded like almost everybody had heard of it. So great job. I also sit on the board for the Cloud Native Computing Foundation, which is the home for the Kubernetes project. If anybody wants to engage further after this talk, I've spent way too much time on Twitter, so you can always find me there. My DMs are also open. So with that communication thing done, I just want to do a quick primer. How many folks here are familiar with continuous delivery? Solid, solid. So just to make sure we're all on the same page, I am not talking about continuous deployment today. And there's only one difference between continuous delivery and deployment, and that is that in the delivery case, there is a manual push to prod. And oftentimes, businesses do that because they have regulatory reasons for GitLab. It's compliance, something we're working through right now. So that's the only difference, and that's what sets it apart. Is everybody here familiar with Kubernetes? Awesome. Well, I don't know if everybody heard me on that side particularly. Raise your hand if you know Kubernetes. All right, now this is good. So as we all know, Kubernetes is an orchestration system for containers, and it's only just the biggest block Buster project of all time in the late, lately. No shade on Git, Linux, et cetera. All right, with that baseline, let's get started. So today, what I'm going to talk to you about in very fast words is the GitLab case study of moving to continuous delivery. And the key message that I'm going to try to pass on today is that don't necessarily go run to the newest, shiniest object in tooling when you're trying to change workflows for a business objective. In our case, we went to continuous delivery without Kubernetes on our legacy system, and I'll show you really quickly on how we did it, what the benefits were, and some humble pieces of advice if they help you in your work in daily life. So why do we care about continuous delivery? Simply because I think everybody here is familiar at this point that for business survival, we need to be responsive to our users and customers. The only way to do that is to ship fast and resiliently. Who here is not trying to ship quickly? All right, one more person. You're listening. But yes, this has become such a mantra for all businesses today that we need to get there. And instead of having, let's say, two-week, two-month, quarterly issues that you work through and stories that you build and then get feedback from users on, if you make quick, small changes, put it out there to your customers quickly, you get a response, and then you keep adjusting to reach the optimal solution for what your product should be. And that's why cycle time compression is important, and that's why continuous delivery is important, because without that, it's harder to ship fast. So how did GitLab do it? As I said, legacy first. So as some of you may know, GitLab has millions of users, and over 100,000 organizations rely on us. So it's not like having a Greenfield project where you can do everything new, fangled, and awesome. So what we did, so in terms of our tooling, GitLab runs on GitLab, so that helps, everywhere from the issue planning to the version control to the CI CD pipeline security and post-production monitoring. But we do not use containers just yet in our environments. We use virtual machines, and we use Ansible scripts to orchestrate. That's pretty old school by a lot of people's standards. It's definitely not all-in-cloud-native, and that's been a conscious choice that we have done in order to get to CD, in order to train our workforce, and in order to really get the benefits of shipping quickly. So there's a little bit of Kubernetes in the product with feature flags, and people can review changes live, but that's more a GitLab thing, not part of the CD pipeline thing. And what has that given us? Well, we go from commit to Canary in two hours now, which used to be over a day in the past. We've gone from weekly to daily deploys. And keep in mind, this is because of the manual button push that we still have to do to deploy to production. The delivery thing is, as I said, commit to Canary two hours. And then finally, and I think this is the biggest thing of all, all of our developers are now on an on-call rotation, and we achieved this in three weeks since we released the continuous delivery system. For three years, as a company, we'd been talking about this to go from Dev to DevOps, and within three weeks, once we implemented this, we were on it. So what did we get? So we got a culture shift, and this is what I suggest to you as an audience listening about a continuous delivery talk. Focus on one element. For us, focusing on culture shift without having to change our infrastructure as we moved to CD has helped us put quality at the top priority. So the way the pipeline runs, if the automated test failure just sends a Slack message to the team, and they have to fix it before it'll go forward. And we do not do any hot patching anymore, unless it's P1 and S1. P1 being priority one, some user is deeply affected, but S1 being it's a large-scale problem. It's a compliance issue, something major. And as I said, every engineer is on the on-call rotation. Doing what we've done, we have actually maxed out our legacy system. We went from weekly to daily deploys, and we've had 24 releases in July compared to four in May. And now we have bought time to join the Kubernetes boat. Now that the operations team is close with the developers, everyone's coming together to devop. Security has regular sessions with the developers. We're a point where we can join the Kubernetes boat. Being on GitLab kind of gave us some advantages, but the tooling decision was really important. And as I said, humble advice. Figure out the workflows first. Get your team ready. The rest will follow. Don't use shiny objects before you're ready to use shiny objects. And decouple big changes, like infra changes versus people changes. And that will make Kubernetes delivery a lot more doable. And that's all I had. Thank you so much for listening, and I hope you have a great day.