 So thank you for coming to my conference, it's been going well for you. So today my story is actually a story about a start-up and how we adopted GateLab and how we've been slowly using more and more of it and how that's been really a big part of our journey in the way we shape our software delivery and the way that we do our software delivery. So who am I? I'm Haas, I'm a software engineer and GateLab user. I'm co-founder and CTO of Ninefin, the start-up which is the subject of our story today is my very first start-up. Before I took the really well-informed and great decision to leave a job and do a start-up, I was working at one of the largest investment banks in the world, not too far from here, London Wall, where I was working in the technology division of the equity trading business. We were doing things around computing systems that measured risk and helped in trading activities and market activities. So on Ninefin, what do we do at Ninefin? Well, Ninefin is a growing independent provider of analysis, credit data, news and financials in the European high-yield bond market. What does that all mean? Well, essentially, information overload is the name of the game of the last 10, 20 years if you're working in professional services, there's just so much information and it's so difficult to even get everything in one place to make an informed choice and informed decision. The same is the case in financial services as in any other thing you've experienced in your life. So we build tools and systems based around the computer vision and machine learning which automates a lot of the manual work of extracting data and understanding what it means, so that we put it all on our platform in one place so that it's easy to search, filter and analyze. And investment professionals can just make better decisions. First of all, a shout out to the team. So a lot of what I'm talking about today is the results of their hard work and I get to stand up here and take all of the credit for it like any good leader will do. So actually, if you are here in London for the first time or you're in this part of London for the first time, that picture was taken at a cafe not too far from here at the canal which just has board games, rows and rows and rows of board games. So if you are into that, just search board game cafe and it'll come up. So what are we going to talk about today? This is what we're going to run through for very simple sections. And with that, finding GitLab, let us begin. So I probably came across GitLab first in a hack and use post. I know Sid, the founder, is quite active on that platform. And aside from all of the software engineering stuff which they're very open about and transparent about, for me, at that particular time, it was really useful to read all of the company building stuff that they were talking about. Because unbeknownst to me, building a company is really hard. And all of the stuff that they're talking about, the handbook, the transparency, the way that they kind of build an organization was really quite beneficial to me at the same time. So you can go to their blog and the archive goes all the way back to 2011. So we found GitLab only in 2016, but there's another five years of history before that time. So before GitLab, we were just myself and my co-founder in her kitchen. We had already quit our job, so we had no choice but to start working. Basically, there was no issue management or kind of organization. We would just talk to each other and then we would go and make the thing. And this didn't last very long because even though we were perfectly aligned with each other and it was early, so there was no tension then, we would forget the reason why we agreed to do something. It's like, oh yeah, but why did we do that? Or like, ah, but this edge case here. So that informality kind of had to change. And so I went searching for a tool. We were already using online host control, which was kind of what was the obvious first step for us, but that's all it was. So I was searching for something that brought together only three things. Private repositories, issue management, and a wiki. That's all I wanted, just those three things. And back in 2016, GitLab really was the only thing that had all those things in one place. So CI, board, chart, container, cool, whatever, don't, some point in the future. And this is a screenshot from probably an out-of-date copy of the onboarding email I got back in December 2016 when we first signed up and started our first organization there. So now that we have it, what did we do with it? Well, the answer is nothing specific. We installed it. Oh, well, we took the GitLab.com online hosted, and it was there. We made our projects kind of at the start, just a few projects. And then as more and more people joined the team, you can see the slow creeping up of a number of repositories that we have up to just under 50 now. And we do a lot of serverless, so that's why we have a high number of functions and also even things like our HR is in there, our PAM book is also in its own repository. So that's where the total number gets to. And I think kind of in hindsight, it was probably really good to just know that those tools were there so that we could spin up a project and not having to extend the license or having to look at another tool. We just kind of got on with the hard enough task of trying to start and found a company. This is another great example of how we specifically kind of used that central place of work. So our first CI pipeline came maybe a year or so into us running the company when a couple of more engineers joined. And the first CI pipeline was the result of our first engineer hire getting tired of manually building and deploying from his laptop. And so what he did was he found the docs, he stood up a virtual machine inside our cloud environment which became our runner, and he started deploying from that. And I actually didn't know about it until a few jobs had been deployed this way and kind of this shows how easy it is for anyone to find what they need and kind of get going in this open ecosystem. And this graph kind of shows graphically what our graph does. Shows kind of the number of CI files offered by me is only five. The number by someone else in the team is more than double. So typically maybe historically you would kind of have this one person who is the oracle of the source control system or the CI job and no one but them touches it. You know, we didn't want to do that and that's not been the case for us. So we were embracing it. We were using it, we were growing a bit, and we were using more and more. We were starting to get more advanced in kind of the type of stuff that we were delivering. We were starting to use more and more features. So there you saw we were using CI, but we were using the board in more advanced ways. We were making use of the APIs. What could possibly go wrong? I'm about to tell you something that went wrong, aren't I? So let's reset to start of this year. Yeah, so January 2019, the main 9th-in.com site, which is only one of the 50 repositories that we have now, was being fully redesigned. But the difference from three years ago in 2016, it wasn't just two people, it was at this point eight. And typically the way we would manage our projects up until that point was that there would be a single person that would be kind of running that project in terms of knowing that the issues are coming in and doing the changes. Not to say that only one person worked on a project at the time, but there's someone who kind of, yeah, this is their stack, like this is their particular project. But with a whole site kind of involved, front-end, back-end, the hater base, that couldn't all be owned by one person. And at the same time, we had extended to, this project had two back-end engineers, two front-end engineers, a designer and a PM, and the part that made it even more great was an annoying founding team of myself and my co-founder. And also, people were playing multiple roles, so one of the back-end engineers was me as well, as well as being the annoying CTO as well. So what was happening is as we all had our different priorities, this was the first time kind of having a dedicated PM on the project, kind of that first point of having engineering have this kind of intersection point. As we were all trying to achieve our different goals and objectives, we were kind of stepping over each other a bit. And our communication was starting to kind of not be as good as we would like it, which is funny for a team that could actually just stand up and see everyone in the room. How could our communication be not that great? Well, the answer is it wasn't totally dysfunctional, but it's the small things that kind of meant that there was a little bit of friction, and it actually did have a real impact on our product output. So I put together this kind of illustration of, I guess, the three months leading up to mid-May and kind of how our releases go. So the red are the creation of issues that are tagged as a bug item, and the green is our releases. As you can see, those releases are patchy at best with long gaps in between them, and more often than not, after we had one, there would be a spate of bug reports. So this was all during the beta test phase of our new site. So this was all either happening in our staging environment or happening in our kind of beta area. So it wasn't in production yet, but for us, we hold our staging environment in our test environments in almost as equal regardless production because they're quite a similar copy of each other. So if it's showing bugs in staging, we feel it as like, oh, it's effectively the same as a bug in production for us. So what happened? As we were starting to get these different conflicts and clashes, and what I like to say is that our rhythm was being set by the problems we were having. It wasn't our rhythm that was helping us to overcome the problems. So we would release, we'd find bugs, we'd stop, we'd have to stop things that were planned for the next release to fix the things from the last release. We were like tangling ourselves off of it. So this resulted in the merge lock. So yeah. So I don't want to be too dramatic about it, but it was not a fun period of a few weeks where I removed all merge privileges from everyone. Just from this specific project, so all of the other projects were kind of going along fine, but because they were in this prime model of like a single person owns it and kind of controls it, but this ninthin.com, I really wanted to find out what was our sticking point. And I've never been the central point of checking of code or merge requests, and I don't intend to be, because that's inefficient and that leads to a very difficult to recover point. So, and that was kind of, some of my old roles had that in place and I knew I didn't want that in place. So we had to figure out, okay, how can we overcome this now? Because on the surface, you might think, oh, it's a startup where some friction is good, but actually if you don't sort it now and when the team gets larger, those frictions become kind of a bit more insurmountable. So I took the decision to, okay, let's put the merge lock in and then essentially talk to everyone in the team to kind of understand what was important to them in how we deliver projects, how is the current process that we have slowing them down or speeding us up, and actually that resulted in me kind of writing a report which kind of, which was a summary of what we thought we wanted to do and how we could do that. So, in true GitLab style, I've actually made the document public. So if you go to blog.nithin.com, it's just a page and a half, it's a small Google Doc that kind of has my findings, but I think it's worth reading out the opening paragraph. The consolidated feedback showed that the friction points were always at the handover between people and that this was not clear slash working for everyone at the same time, leading to unknown states of what to be tested slash reviewed and by whom and what should be worked on. The result of that was the merge lock, which has been in place since April 8th. The two principles I want are development not artificially slowed down. I move as fast as possible and the state of what's in flight and what is planned for future releases is knowable by anyone at any one time. I've actually read that until I came to prepare the slides for today in a few weeks to go. So I thought, wow, that was quite a statement from myself. Maybe I was being a bit too dramatic, but in my talk abstract, I mentioned the surprising human factors. This was case in point, the surprising human factors in organizing a team of people to deliver something and in particular in the world of software. Things are a little bit more abstract than you'd think would be more scientific, right? So what did we do? So my doc kind of talks in full, but here are some of the steps which were enabled by GateLab. So the first one, you know, more internal communication. We wanted to make better use of issues, so we wanted whenever a new issue was made, we'd like something more than her title, please. A description, how to make it, a screenshot, behavior gif, you know, is 2019. And also just more show and tell. So again, because we are remote, but one of the strengths of that is that we're all in the same room. So if one of the engineers has got something on the local development machine, say ask her business user or basically or take a screenshot of it and let's send it to a client. There's no need for this kind of rigid handover process of like it's done, it's working. And then we have to track back after we find out that actually it isn't. Why not have her PM who is kind of sometimes a proxy for her user come in and sit down and try and use it and go, yep, that does what we want. And then we don't have to think about having any concerns about is it gonna be wrong down the line. Make more use of, so we need to release more often and make use of kind of review apps, which I'll talk about more later. The next two are linked, so more frequent releases. That necessarily meant the improving of our testing capability, our CI CD capability and some chat apps, I'll talk about later as well and invest in the automation tools to kind of make that possible. And the final one, this is interesting, so this is not enabled by GitLab as a product, but maybe enabled by GitLab and Spirit. So this was, I kind of felt sometimes that there was a bit of uneasiness from the team about taking actions on the repository. I would say, look, whenever you do a merge request, the pipeline here appears, just press the button. And there was sometimes a fear when you're gonna launch the nukes. Like, obviously it wasn't, but it just kind of not understanding the tools that you are using is a really big factor in teams being, if you're trying to explain the inexplainable as to why a team which is great on the surface, individually fantastic, but kind of coming together, this might be something that might be worth exploring in your organization. So I said about a process of for a few weeks, I would do a session called Know Your Tools, and it would start with really basics like what is version control, Git, SVN, Mercurial, Purpose, you know, where did it come from, why is it important, and then also branching strategies, GitFlow, GitLab, Flow, Trunk, CICD, what does GitLab do, what do other providers do. As you can tell, I really like having context to things, so even whenever our interns ask me a question, before I answer, I go, well, actually, you know, the interesting thing about internet protocol is, and then 20 minutes goes by, but this is kind of in this kind of day of age where everyone feels a bit in process syndrome sometimes, and kind of not wanting to raise your hand and say, oh, I don't know that, or like, I know Git, but there are a series of steps in our history that made us land at this particular path, so I felt that was really important. So did it work? Hey, how are you? As you can see, our releases are a lot more frequent. We release every week on schedule, but we have the ability to release the branch at any point in time, so the host blues are just random hot fixes that we needed that day. Again, all done through GitLab, CI, so press the button which everyone feels very comfortable doing now, and apart from like bug bashing at the start where we kind of got everything out, decreasing rates in bugs, and now, this definitely won't last, but we've had no bugs after releases for about two months now, so that's been great. So where do we go next from here? Let's talk about extending GitLab. So we're on a roll, so this diagram on the right is basically the software development life cycle. I have taken artistic license with his image, which you can find on the GitLab homepage, and I was really interested in this loop. I was interested about two things. So for us, a lot of the steps we do in GitLab, but not all of them, and that's fine. Not all of them are meant to be there, or again, in your organization, might not be there yet in the tool of your choice. I was interested in two things. Productivity, which I felt meant how fast can you get around this loop, and visibility. Can you see in from the outside and know what is happening inside that loop? So let's talk on the first one. Visibility. So what is visibility to us? So it's being able to answer the question as to what is happening in the repository at any one time, and the question that you might get asked, hey, where are we on this, is a lot more confrontational than it needs to be. Even if it's just an innocent, just someone that has been away for a few days and they want to know, like, what's up, people think, oh, I'm now going to be, this is going to have my life flashing before my eyes, I'm going to have every semicolon examined, and every bit of white space is going to be checked, but it's actually tabs or spaces, depending on how you're on your code reviews. But no judgment. But for us, you might say, okay, that's actually quite easy. You just open the issues board, and you click to here, and you go to your project, and then you go to your filter, your specific view. I mean, it is easy, but especially if you're not in the project at a particular time, you might not even have the browser open at that page. But we're all in chatbots, but we're all in Slack, right? We're all in some kind of chat function. So we built the chatbot. So shout out to our intern who built this in six weeks straight in the summer. Touched Python before. So she built this all including deploying it to our cloud. And basically, it's just a really simple chatbot that I can ask of it. Please tell me all of the issues labeled staging or this particular thing, and we can do search operations that involve more than one label, which I know is something that is a pending feature here on GateLab. And this has saved me a lot of time, because even when I'm doing the release notes, I tell it, hey, get brought, show me the issues that are in this merge, which is her merge release. And I just copy-paste it, and there we go. And I can go code asleep earlier, which as a startup founder is something which is in rarity in my life. So let's talk about productivity. So this is the SDLC as you might know it, so software development life cycle. We have commits and mergers which get integrated in your control tool of choice. And then from there, continuous integration takes over and will build or manage the artifacts and will put them somewhere. And from there, they might go to a staging environment and then once some all-clear signal is given, they'll go to a production environment. But I want to preview some changes. I want to preview a single change. So let's take a look at that staging step for a second. Staging is where what I call high-value testing happens. The type of testing which cannot be written as code or cannot be automated. It's stuff like the feeling, the intuition of the platform, has it slowed down a bit. Now we are making strides and making tools that can do that automatically, but nothing beats a manual sense check at the end of it all. And what's great is if we can get that as early as possible in the cycle, ideally before it's on your staging environment because the issue of doing it on staging is that you're waiting for some magical integration point which depending on how you run your life cycle could be at the end of a two-exprint or it could be in a Humphrey release and even when it does happen, there's normally more than one change inside that particular build. So with review apps, you take a single commit or feature all the way through and you deploy that in some sort of temporary place. So for us, that is a review app and you might already know that already exists in GitLab if you're using Kubernetes. We are not using Kubernetes. We use a different container orchestration system. So I thought to myself how hard could it be to make one. And I just published this morning using GitLab CI. My blog post which kind of explains how we did it using our cloud provider who might be the same as one you use but we kind of realized that any orchestration system plus a bit of scripting in HCI, you can get quite close to achieving this particular feature. So for us, whenever there is a pre-merge, there is a pre-merge pipeline and you can build the images for preview and then you can deploy them and then a bit of scripting at the end of the job spits out the IP address to where your particular app is running and you can go have a look at it. That can happen at any point. It can happen multiple times before the review, during the review. You can even do it on your staging environment. You can do a load of them at a time. So this is new for us. This is probably our newest bit of building on top of GitLab. Like I said the feature already exists if you are on Kubernetes already and we're just having conversations with some of the GitLab team today actually being able to do it outside of a Kubernetes environment is also something that is in the works. So all of my work is wasted apparently. But it was interesting to learn the capabilities and how much I could actually avoid doing by just leveraging GitLab CI and particular cloud provider orchestration. So in some way there's a lot to learn from GitLab from both the content that they produce so in the blogs, in the transparency and the openness, but also by example, go look in the codebase. We have a Python stack which is not quite the Ruby on Rails but Python, Flask, they're not a million miles apart from each other. So actually when we were coming to build some of our automatic testing for end-to-end testing I was trying to think of what level do I need to pitch the test cases at. So is it like super fine-grained like this button must be here or is it more of the when I'm doing this and that. So I went in the codebase and I found the way that GitLab described their end-to-end tests and it was at the level of when I'm doing a merge request. So then I just I took that. And I think they're very okay with that as well. I think install it and they will come. This is the idea of if you've gone through the trouble of bringing it in your organization or by using it try not to lock it down unless there's very good reason for doing that. We found CI because of a frustration of one of my colleagues and he was able to find the docs and to go and do it himself. And sure everyone knows the why in your software development lifecycle. So that's just the history, the context of hard fought battles. You might need to tell them on a regular basis to whenever someone new joins somewhere they can understand. GitLab would probably say document it somewhere. But if you don't want to do so much writing it's fun to sometimes rehash the stories with people and to explain why things came to be. And finally extend and build kind of only when it works for you. So every organization is different. The decision to buy a build is always a trade-off. So understand the reasons why you're doing it and what you hope to achieve from it. So on that I will stop and I will welcome any questions. All right. Thank you so much. Do we have any questions? Hello, great talk. I was wondering if you could talk about how you decided between going for an on-premises GitLab installation versus using GitLab.com or using a third party. So as a startup I want as little extra things to think about as possible. So it was online it was there I think maybe being a newer company I don't have any perceived kind of irrational fear of not having something self-hosted. So in the cloud it's probably fine. But we did put our GitLab on us in our own cloud but that's purely actually just a lot faster and you get and you have and you can use as many as you want then. So the decision as with a lot of things in the first few decisions I made was like convenience and practicality that really trumps a lot of things in my life at the moment. So you're saying that the rest of your organization is using GitLab as well. How is the process for those not working on technical areas to embrace GitLab as a way to use the company as well? Everyone uses it including our kind of business users and again like so the company is only 10 so we had a 10th employee join today. So we everyone uses it because it's the way to understand if you've asked for something what better way to see if it's going through the process than having a look at the board having an issue board and I think yeah I don't think it was an intentional resistance to like not using it at the start if you come from non-technical backgrounds in other firms and companies you wouldn't have used this host control system before so it might have felt weird to not have things in spreadsheets. So just after I don't think we'd tend to face any resistance to it we just kind of showed you know the thing that you asked for let's write a ticket let's put a title if you know what you wanted to do then write that down as well and if you got any mock-ups any screenshots we would welcome that and then kind of people realize that actually this is actually better than having my own offline spreadsheet somewhere. I can actually put it here and I can forget about it and I can tag it and I can search it and find it again. So I think just by leading by example but kind of help if there's someone that has a whole bunch of ideas you maybe might be able to help them put them on ticket lab issues if that's what you use to track your top-level features and then hopefully they will they will see that it's great and they'll keep using it themselves. There's some idea about what sort of branching strategy you employed like you had two back-end developer, two front-end developer let's say they are working on feature one, feature two. Most of the time how frequently release depends on how frequently you merge a call. So if you can just put some insight into that. So a big part of our I guess another reason why we had some slowness in the deployments before we kind of had this big sit-down and talk was long-running branches which is a problem that we might face so it was about understanding you can have features that take a while to build but can we commit something in the intermediary so can we have that branch close sooner and also we did get better at doing things in a short amount of time not by just magically becoming super engineers of all of my team are super engineers we just got better at scoping we managed to cut down and scope back a fully releasable version that was maybe a v0.1 and then a v1 and a v2. I think kind of what I found in my old job is that people fear that if you don't get it in this release they will never get it in so they try and ram everything in but actually understanding actually we can make version one for this Friday's release I guess we do release on Fridays but with no bugs for the past two months so who's right now we release we can release every week so if version 0.1 is done on the Friday you can start work on version 0.2 on the Monday but actually isn't that oh we're going to take all your resources away from you so kind of people can understand that yeah we can deliver in a continuous way and I said to the team yeah it is a bit more work to implement your design in a way that can be delivered in phases but that's normally worth it because you can get it to your customer sooner and you can decide if it's even worth to do version 2 rather than building the wrong thing in the first place tell me merge lock April 8 how did you decide that date specifically so it wasn't yeah so I don't think it would have happened if we hadn't been fundraising at the same time so me and my co-founder fundraising if you're ever lucky enough to do it it started as a process which takes your life soul and energy it's like when Voldemort's soul up a few times and it's kind of that draining so I think it was a combination of things and at the same time I'm still an active contributor to a lot of the repositories that we run so kind of I was just seeing releases on staging and kind of obvious bugs that were like well we could have found this so merge lock sounds a lot worse than it is because actually didn't slow things down by that much because we were getting towards the tail end of our development of the site so it was his period where things were we needed to have this sit down and review of everything but it kind of just brought home the point that you need to have a working and smooth process and that doesn't necessarily depend on the tools it depends on the people you have with you awesome thank you so much thank you