 Hello everybody, I guess most of you are expecting us to present or introduce ourselves to turn a little bit of just topic and to drag it through representation, right? It is exactly what we are going to do. I'm Boris Wagia, I'm a Software Engineer at AUSIS and today with Yannick we are going to share with you our experience on what not to do or using GitLab. I guess a lot of people are a little bit confused and are expecting something they don't know from this talk, right? Because the topic is a little bit controversial. First of all, why is this topic? Most of the time when people start adopting a technology they just read success stories and just happen over the time. When you start your systems you will see that what drives people is the latest innovation, the latest hip that we have in the world and particularly in the software industry where we have new technology popping out quite frequently and people are curious. Enterprise and company just want to move forward to adopt the latest thing and this is why we chose this topic. Why? Because when you adopt a new technology over the time, when you are in the rates of success stories, you end up hitting your head on the wall because you have a success story and then you start investing in it and then you figure out that, yeah, maybe I shouldn't have done that way, first of all, I should have taken what I had to my current setup. The idea here was to share our experience and what not to do to prevent people starting to use GitLab for the first place or when they start using it at least to be aware of stuff that they shouldn't do. So what are we going to talk about? We are going to share a little bit of our GitLab adoption history. We are going to describe our challenges, then how we solve them and then go through again those meta-patterns that we have learned since then. What does the meta-pattern that we have learned? I would like to share that and share it with you and maybe also learn from you too. Yeah, our challenges. Already in the year of using GitLab, we have a lot of problems. But first of all, what happened? I mean, since we are starting to use GitLab, do you want to give us a little bit of information on our GitLab adoption so far? Okay, we started using GitLab in 2013 after face several problems with our whole version control system. At the beginning, that was very difficult to adopt it because it was new for us and we have never experimented before. So after many tries and hard work, we start to understand how this work and we are able now to use it. So actually, we managed a GitLab instances with more than 1,000 projects, more than 1,000 active projects. I'm talking about 450 active developers more than 2,000 built per day. So this statistic just to give you a basic understanding on how our infrastructure is built. To get there, we had a lot of pains to go from 10 developers to 400 to go from 2 projects to 1,000 projects. Then we had a lot of challenges that I'd like to share with you. The first challenge that we had was availability. What do we mean by availability? As the time was going on, we had like sometimes some random crashes, right? Some data loss and it was not obvious for us that was back in the days and it was quite difficult to debug. Was it GitLab, the problem? Sometimes you had an infrastructure that was working like a straight year without a problem and one day you just have all the data done, all the systems down or whatever. It was quite complicated. We started to think, okay, maybe this new spoiler doesn't make sense at all. Shall we switch and so on? It was a little complicated. Those problems were not quite a problem. The problem was to investigate a step further. What is the problem that we have? The meta problem here. We looked through everything and actually GitLab was not the problem, but I think our infrastructure itself, the way we were hosting it, the way we had GitLab installed and as we were growing, I think we needed to upgrade. We needed to move to something better because we had a lot of infrastructure problems. What we did, to solve the problem, we just looked around to find a provider who can give us a calibre infrastructure or a calibre resource and then we looked on the market and chose Amazon that had a good offer for us and since this time we are running without resource problems and we are satisfied. Yeah. Today we are seeing the product itself is moving more and more with the collaboration with Amazon. We saw what we heard today from the CEO. At the time we had to switch to Amazon to have some better hosting of the product itself. Then the second challenge, as you grow, you have a scalability problem like extremely low services. Yeah, we are running on Amazon, but at some point you figure out you have 60 customers running on your instances. Developers from some teams were complaining about the pipeline because it was taking too much time. People get frustrated because the service was slow and it was probably paying after, I mean, you switch from 50 developers in your team to 300 and without refreshing the environment and then you start noticing some patterns like slow pipeline team are really frustrated and you have a lot of memory issues on the problem. So we investigated and then we figured out so many customers using the same instance and you know in GitLab you can create group and in group you can create projects and assign users there on the same instance and managing and handling our customers that way was a little bit complicated and we need to fix this because it doesn't make sense to have a team from a customer to be brought because some other people are working on the same instances and consuming the world resources and it was pretty annoying. We thought about it and we said, okay, we do something completely different. What's the problem? We decide to supply our infrastructure. We decide to deploy for every customer one GitLab instances that is like a small instances and then the client if our main instances is down our client will not be affected because everything is applied on each run inside the whole instances. Correct. Partitioning first of all is a concern computer science. That means keeping things separated to avoid problems and we wish really that we had this experience of you know having things separated for a better life during our production and this problem we had it like back in 2015 and 2016 and we had some requirements that we couldn't fulfill. It was quite complicated and we have some requirements and you need to you know sometimes customers say, hey look we want to do this. We have this software development and we have this process that we want to implement. We want our product to be deployed over this night or in this way and so at that time moments arrive where the product itself, GitLab itself is do not have what you need and there are a lot of ways of fixing it. Either we say hey look we cannot do it or we say yeah we will implement a custom solution and this is what we usually did over time like okay we want this feature we try to implement a custom solution and then tomorrow with a new release. In this situation we implement a release concept that means we upgrade our system each time GitLab publish a new release so it's like after Git. Yeah the idea here was we have some problems we have some new features that we want. We have two ways either we invest time in fixing that or we say okay we don't do it we wait the next release and fix it and left the customer with the problem until the next release come. So yeah so far that was our GitLab adoption journey and the next step was yeah a picture of cats because cats are cats and there's nothing we can do right. Yeah so what not to do and really what really not to do when you're using GitLab the principle one we would say about it as principle don't fool yourself. Early optimization is the day we adapt as you move. We had this situation where from new releases we tried to upgrade the whole system to fit those new features that came in in the project and after you upgrade the whole environment the system crashed again. Yeah so the first principle is keep things as they are only use what you need and GitLab might come up with some pretty house some features and you can see on the website market everywhere but ask yourself do you need it if not don't use it maybe you might want to use it at some point in time but what we learned was don't change your system every time you have a new feature coming from GitLab. It makes no sense right. Leave things as they are until you need them. That was our principle number one. The principle number two I would like to share with you is the feedback loop. People neglect this a lot but we know this new system means new problem that is the fundamental systematic law. For every system that you start that you bring to life you create new problem like managing that system itself right. So when you start using a feature don't expect it to work as it is described somewhere or by anyone. Implement it but then take the time to gather feedback from people using them and for instance the diverse people implementing feature they are not doing it for themselves they are doing it for developers that are using the product itself right. So when you're implementing a new feature take the time like one two three weeks and get a feedback from people or from your customer and does this pipeline make sense but this pipeline is behaving as we expected. Are people happy working with this if not remove it and there's something we use to experiment. You might have some new feature try some experiment and implementing that feature like some pipeline and have some I mean test the feature you want to give to people or to the developer before leaving it to them right and if it doesn't make sense if people are not happy about it drop it and then don't enforce people to use it and the pipeline here or whatever feature you're using shall be there only to match the development process of the team and not just because the feature is available and it is cool. So you have to keep that in mind it's really important. Welcome next. Train and delegate. Education is the premise of success. We have seen project and teams where over the weekend some developers implement some cool stuff and just push it there and the day after everything is working and nobody know what happened and why it is working that way and then he takes holidays and the world team cannot work anymore. You have to stop that. Train your people, train people in the team, train everybody using in that project, train everybody using that feature or that pipeline or that advanced thing that you have in your pipeline so that people can understand and they can fix them and by people here we really mean our team member exclude product owner. I'm not sure if product owner needs to learn about pipeline but train your developer to know what is happening in your pipeline and to know if or how they can improve it and to understand if there's a problem maybe they can know that yeah in this pipeline you are doing this auto scaling up that is causing problem and consuming so much resources out there or they have to wait too much to have their pipeline done or to have to continue working so you need to train them to understand what is happening and sometimes people want to change the workflow. We are understanding really that sometimes it is complicated to have this workflow that they have and if they understand better the words of the DevOps and there will be efficient in providing I mean there will be efficient in helping building your development process in collaboration with the DevOps. So training people in the team to use the product and understand what is going on on the hood is really important never miss to do that never ever. First number four awareness I particularly love this one right. Don't assume you're the first of course there are smart people out there doing excellent job. Don't assume that you're the first to do it and by this remain trying to learn and collaborate with people. Gild up a service on open source project it is open everyone can learn but we have a lot of teams building custom solution maybe they fit your needs but if they had to collaborate if they had collaborate with a lot of people around them in the community learn and attend events or sharing or exchanging with other people they will learn how they're implementing it. We have found ourselves implementing custom solutions that we really needed to do that and when you go to a meet-up or when you go to an event and you talk with somebody and you just say hey we are using this this way how are you using that and you say oh we are using this and this way and it took us three weeks to implement it so then isolate yourself getting touch with people and learn how they are building the product how they are using the product itself it's really valuable don't forget yourself and say we know enough and we will do it on our own at least that's our suggestion right. So just summarize this don't from yourself don't underestimate the value of foster feedback not all of them are also valuable yeah because some people might give you some feedback and that you really don't need them right. Don't let it out to the supervisor they've obtained the team to take over. If you don't do this you will have I mean if you don't do this you will have some pipeline and people that cannot switch between project right and so on so let the people in the project learn what is going on it's really important really important so never miss to do that and I am very real and try also to learn from other right we all know what this means so so far so good and why doing this we thought about creating a new github community where company and individuals can come and drop their adoption github adoption experience why Sharon is carrying I have a cookies I have a new spark card big house a lot of outfit do you have a cookies no so you have everything but you don't have a cookies yeah just to say Sharon is carrying help other people with what you know it might be a good idea I mean together we are stronger and we can only improve the knowledge in the continuous improvement in continuous delivery and continuous in the integration industry only if you are working together right so this is the idea of this some people trying to adopt the product have no clue how other people are doing it or implementing or using it or how they are building for their use case and the idea here is to say okay let us create a community where people write your success story and your failures is very important you cannot learn only from success story from failures also like we did how we had our problems our challenges how we fix them it will be nice to have an open project somewhere on the world or out there to have a project where an open source project or open source repository where individuals or company can come and contribute and say okay we are using github this way when we have this we had this problem we solved it like this and made it open source so tomorrow when somebody here we started company it will be easier for him to check what happened and what the other people got and did to not go through all that pain and this here was also the key for this talk to reflect on this idea of having a community where people will share your experience and adopting the product also I would like we would also like to get your feedback here all right so with that said that's all we have prepared for decision thank you very much