 First of all, a little bit of information about who I am. I'm a systems engineer in Cape Town. I love all things DevOps and automation. I'm involved with various meetups. I'm also a GitLab hero. I don't have a cape for that, so that's fine. My role in the story, I was a VP of engineering at the small startup, and my role was to hire and grow and mentor this team. So we really had a focus on the product, which comes to my mission. Our mission was to build and deliver features. We didn't have the capacity to worry about all the underlying infrastructure, about hosting a repository, and about hosting our monitoring tool, and all that sort of thing. So we had to move fast. Our application was a single application. We had a monolith, but we had various other tools and stuff around that as well. It wasn't just solely one thing, but there was a few other things we had to do. So our team, as you can see when I started the company, there's only three of us. So again, this reinforces the fact that we can't really worry about the kind of periphery things. When I left, there were six of us. So first of all, why did we want to move to GitLab? A single tool, first of all. We had various tools for various things. We had an issue tracker. We had CI CD, and then we had our code repository. And our fault is that there was just too many things. And I'd prefer if we had one tool that could do the job. In addition, at the time, the free plan that we had suited our needs. I think GitLab have changed it. So it's now the lowest tier paid-for plan. But the business wasn't happy with us saving some money. And last of all, the GitLab CI tool I think was very powerful, considering we were using Jenkins in the past. As the previous speaker mentioned, if you give people buttons to click, they're going to click it. I like the fact that this stuff was configured with YAML. So how did GitLab help us? What did it do for us? So first of all, we used the plan feature of GitLab. This was the issues. I wrote a small Python script to import all of our issues into GitLab. We opened up a dedicated project for everybody in the business to be able to file issues against the product. We also used labels and milestones for various different things in the organization. So it was for agile and sprints and all that sort of stuff. So it gave us the ability to manage and work on our planning. So what this meant was we had a single source of truth. If anybody in the business needed to know what we were working on and why we were working on it, I could send them to one place and they had that there. In addition, it was clear where we were in our sprints and our milestones and our planning. And all those tasks were in a particular sprint that they needed. So again, it was just a single source of truth that anybody had access to. This allowed us to plan better because we knew what was upcoming. It allowed us to plan better because the business knew what was upcoming. And also gave the business visibility teams of what we were doing. After that, once you've done your planning phase, a developer gets assigned a task and they have to go create the code and make a merge request. We used merge request as a way of getting the code into production. There are some great advantages to this and I think the biggest one for me is the peer review. The ability to get somebody else on the team to review code and let you know and comment and kind of just review it and get it to a state that makes sense. Additionally, we had automated tests that ran. We had static code analysis. We had a very small testing suite. But it's kind of just the place before you go to production. And the result of this was increased knowledge sharing within the team. Often there was cross-ponelation. Somebody would be working on a specific feature and somebody else might know a little bit more about that part of the code base. And so generally we could learn from each other and grow as a team. Ultimately, this led to better code and more tests. During my time there, we started off with a zero test and ended with 500. And this just increased the team coherence. We worked well together all because we were vulnerable with each other and could learn from each other. Once the code has been created and the merge request has been accepted, we had to deploy this to production. We used the GitLab release feature. So this is the GitLab CI tool. What I loved about it was infrastructure as code. There was no clicking with GUI buttons. There was just some sort of YAML config somewhere that it was open to every developer so they could learn and understand what was going on and it wasn't foreign to them. It wasn't this black box sitting somewhere else. We also managed to figure out various different patterns for how we were doing deployments and we could copy and paste this across our different repositories so that we all used a similar style of deployments across all the repositories. And I think that was very important and very empowering for the developers. In addition, GitLab CI is in public-facing. There's no way of interface that somebody can go to and hack you. So it was one less thing for me to worry about. And the result of this is more stable releases. Our previous deployment method was a single person of our team are syncing the code into production and restarting engine X, which caused a little bit of downtime. So we've all been there, right? I hope we've all been there. So this empowered developers to do deployments. We could deploy more often. We could deploy smaller changes more often and effectively it increased our stability and the speed that we could work at. The last feature which we started at towards the end of my time, there was having a look at the monitoring tool. GitLab implemented Prometheus monitoring. I was very interested in Prometheus at the time and I wanted to see how this feature worked. So it was yet another single tool in the sense that it was in GitLab. So I didn't have to install a different dashboard. I didn't have to install another tool for this other than rolling out Prometheus, which was incredibly easy to roll out because we used Ansible for our infrastructure and there was a great open source Ansible library for Prometheus. So the result of this tool, the result of monitoring was we could better understand the impact of our code changes. We knew when we made a deploy, if something went bad, if something went well, if it went the way we expected. It also allowed us to easier troubleshoot issues because we had more metrics to look at. And in addition, we could start predicting issues such as scaling issues. So in summary, a single tool for developers, I believe this is important because it's less cognitive overhead. It's one place to go to, it's one thing to sign up when a person joins the company. It's one thing to remove the problem if they leave the company. In addition, it allowed us to stay focused on delivering features. When they didn't have to deploy features and they didn't have to work on features, they found the code really easy to, the GitLab tool set very easy to work on. One of the examples is one of our front-end developers who had never worked on any sort of DevOps tooling, managed to create a full pipeline all by himself because it was written in YAML, the patterns had been set and it wasn't difficult to figure out what was going on. It also empowered developers because they had the ability to deploy when they want, they had the ability to make the changes when they want because it was all there. And then finally, happier developers who were less stressed. And I think in a small team that's moving fast, we want that confidence and we want people to be able to know that their change is going to go out, be happy about it and not be stressed that they're going to break something. So that's it from me, thank you very much. If you have questions or want to chat, I'll be at the evening event. That's my Twitter account at Adrian Moisey and I also have a website I sometimes blog at. Thank you.