 Yeah, hello this talk I will Obviously tell you about our migration from Jenkins to the good laps here. I I will give you a more Detailed inside how we change to get lab at all. So we are we about priestly a previously at Jenkins and GitHub and yeah We are changed our get DevOps strategy and yeah I tell you why and what we changed and especially what we learned so Yeah, first of all, I'm Phillip as fun. I'm from Hamburg. I'm work at at soul. It's more startup out of the other group And working as a full-stack developer mainly I currently doing DevOps and bug smashing at my company and yeah before I joined them in the start of the year I Got deeply in touch with get lab at my school and Fall in love with get left and wanted to work with that and yeah a part of that I'm a good up hero because I'm organizing the good lab meetup in Hamburg So if you are there and one meetup is happening there, you're kindly welcome So yeah And inside of that I'm a heck of school inspired to bring young people into the software development And teach them at a weekend. So first of all, what are our technical landscape and that's all we are mainly Developing spring boot application with the view front end and using a post-class SQL. We are building previously with Maven as our Building tool for us Java applications We used Jenkins and our own docker registry in the private cloud which is maintained by a provider There's also a Kubernetes cluster we use for our applications and yeah Source and product management source by github So what are our challenges? Why we wanted to change our? Defop strategy, so we are really young startup. We are five developers in our company So we have literally no time for everything to do So we need more time for developing our application than focusing on maintenance and our defops task so Because we are Jenkins The building process is a little bit tough to learn because no most of us could not easily read a Jenkins file and this is really Unfortunately Unfortunately when someone is in the vacation so Yeah, and it's an old application. So the old DevOps strategy is a little bit older Yeah, and we figured out our Jenkins is not so stable at all and it's really tough to change them because it's also managed by our provider and yeah We need some speed when we want to change something and yes a little bit of Mimi but the visibility of Development status of issues is important to our product management So it's hard to figure out currently In which state our issue is so yes And we are small development team. So we have to care about costs on our development tools Yeah So what? Yeah, how was our journey to GitLab? I mentioned I got in touch with GitLab before I joined the company So I wanted really to work with GitLab So I introduced my colleagues to that and the first step of all were to gather all information to Asking myself, okay, what could be possible with GitLab? What is How could it affect our daily work and what improvements? Could we achieve with a migration so I gather all information and when I thought okay I have enough information. I started to get into My colleagues and speak to every specific rule where change with GitLab so yes I had several feedback feedback loops with every specific rule and Then in the end we committed with the world team to test GitLab at silver status So we using the SAS version of GitLab and yeah We said okay, let's try GitLab out So we started with the small project first We gladly had a small project where no pipelines at all. So we had a green field with our DevOps strategy so we Said okay before we start Let's think about how we want to build our software So we really We're deeply thinking okay what we need do we need testing? Yes, of course, it's obviously so which state of testing we use and We need and we try out something new for example we use Gradle instead of Maven because it's really More flexible for separate jobs in different environments Instead of Maven yeah, and we had a we had to find really We had to find solutions for our private cloud cluster or private cloud solution by our provider Because that can secure the concerns like how we connect to our Kubernetes cluster to deploy some app from the GitLab shared runner That was a really big issue. We solved them with Providing our own GitLab runner in Kubernetes so we had to Find out this is the right way because the GitLab runner is talking to gitlab.com and not GitLab.com into our cluster. So we don't have to provide a VPN or SSH tunnel Yes, and we had some other Challenges with our GitLab runner in our Kubernetes. I will mention on the next slide and yeah We tried out something of the GitLab Features like the Docker registry because we are running our own or getting our own by our provider So we tried out the GitLab registry So what are what were the what were the challenge with GitLab runners in our Kubernetes cluster? The important thing is caching. We had a lot of dependencies in our applications So we started with no caching which only downloads the sources and we had to stable duration of each step and We don't we thought okay, this is not really good for for a good duration So we want to want to speed up our building time So we tried out s3 caching by default And we figured out her okay. It's downloading and uploading the sources. So it literally doubles our duration and We got out or this happened to us that the upload of the sources Could fail so we had sometimes 30 minutes to wait Until the sources is uploaded and this is not a not an option for us and Another thing where a local caching so you have persistent volume in your Kubernetes cluster for dependencies and Mount them into your GitLab runners But our provider we are not supportive on that so we could not use that but this is maybe the final solution when you are providing a private cluster and your could not use the AWS or Google solution for caching Yeah, and notice we are using a private cloud Kubernetes cluster I think the when you are on AWS you don't have the problems so in the end what changed to our technical landscape after the test with the small project so we moved away from Maven to Gradle because it's more flexible and and In our private cloud we are only use the Kubernetes cluster where our our GitLab runners are working and connected to GitLab and we use GitLab for every every step So product management source hosting and CI and Docker registry and this works really good So we had our small project So let's move on with the main project. This is a really huge main project with which is a really old application and we thought okay, it's really good to do it in three phases and The first step. Well, okay move the repository simply to GitLab and link the Jenkins to the new origin So we use that we use the GitHub import by GitLab It's nearly run smoothly, but we had a lot a really big issue with the migration of our issues and releases and tags which are not transferred because no reason we waited every time over a day then the Job said okay, he could not migrate our project, but the sources are still there so it will Really confusing, but we found a solution. I will mention on the next slide so And the second step of the first phase where okay, let's modify the scripts to to to the new origin We exchange the GitHub API calls with the GitLab API so Yeah, that was really easy and we had a stable build with our new repository so we could move our project management to GitLab and Do not need GitHub anymore So this is our building step in the old version of our big application, so we had to get check our job and Jenkins Which is automatically done by other great tools then we had a huge step building and test and Finally when everything is fine, we deployed to Kubernetes This could which could be possible in five minutes and sometimes several hours depending on the customer when there's running a job so Yeah, for the problem of the GitHub issue issue We Created an open source GitHub issue migrator, so everyone can contribute. It's a CLI tool which You easy can can configure that you are Saying okay, this is my project from GitHub. Let's move it to GitLab so it's also fine so Right user of the the right owner of the GitHub issue, so it's transferred to the GitLab API GitLab user, but you have to do the mapping manually, but it's a lot of helping so yeah, and you can move your Releases and tags also yeah, and you can find it on the GitLab It's not so much perfectly, but when you have the issue you can use that and help Yeah, and then we stepped in the second phase Where we thought okay now we are on get a good lab fully with our Application so let's do a lift in shift. So we started to create a good lab YAML CI YAML and Try to simply lift and shift that the three steps, but Our thought were completely wrong our Process were really far too complex to and make an easy lift and shift because Yeah, it's where one Docker image would have Which contains everything and We found out okay We need too much time to get this running and let's skip the phase two and go directly to phase three yeah, and Cool pro tip if you're running your own Kubernetes GitLab runners increase the log limit if you have to debug your Application or your building step because when you are debugging you'll produce a lot of Information and the UI is the only source of your logs I think so And the standard size is for maybe bite. So this is not enough when you have a really long logging step Yeah But it's only possible when you provide your communities your good lab runners by yourself so We skip to the phase three. So we have to I named the proof of the Good lab as the CI CD pipeline. So we Thought about new ways of building our software. So we split every Step in one step. So like it's a job in the good labs here. I am so and our Idea was okay one job does perfectly one thing so we had That each rope is simple and everyone can modify it easily and we have small environments So we don't have to build our Docker images on our own and this is an example from our Small project a pipeline So, yes Yeah, which I mentioned especially in the third phase we Moved then to cradle Yeah, we tried previously one with maven, but we use cradle It's more fits to enter our new DevOps strategy. So Yeah, it's also improved our building time a little bit and It's where more flexible and everyone knows how to use cradle instead of XMLs so yeah, and we tried our parallel job processing. So like our unit tests and integration tests are Running at the same time. So we reduced some time some building time there and Yeah, and a huge impact where the that we are using standard Docker standard Docker images So we don't have to maintain The docker images by ourself and Yeah, this is far Far far less time for maintenance needed to to change the gillip CI yeah, and mostly the official Docker images Fits our requirements. So we don't need we don't have the need for a specific Docker image so What are our key learnings is? Yeah, what are our key learnings for migration? so One of the biggest issue is to plan your migration really detailed It could have really in the beginning to get every member of your team To know what's happened when we migrate to get lab like what changes to the product management and Case of okay, this is works in this works in GitHub and now this is different to get lab and Yeah, plan your migration well and especially take your time for the migration. It's not okay. We need two days and then we are finished take your migration and especially do it step-by-step. So Because we are using the three phase Plan We are able every time to deploy a new version and continue to work on our project. So we could improve our application without Yeah Without to wait for the better infrastructure so And yeah When you have time for your migration use it for rethinking your completely deaf up strategy. So when you are Yeah, use the time for something out new and Maybe okay. Let's do more security issues or automated security which is really important and Yeah, use it for for rethinking your deaf up strategy and Yes And yeah, when you have the possibility Star Wars small project Especially with with your colleagues so spend like an evening or something more To do it together and that everyone knows what's happened when they are using a good lab See I yeah, and another pro tip keep your pipeline user friendly. So we use a lot of commons to structure our Our config so we have a good overview and Yeah, it's really really nice to have a good user experience in your CI so you see everything on one side and Especially comment your variables if you're using them. So sometimes it's not really clear why or What for what purpose the? Variables So Yeah, and in the end why good labs suits us perfectly as a small company and tech team so The important thing is the powerful CI CD solution. It's very recustomized a customer as a custom Customer stability You know the words Yeah, it's really It's we have every project on there and don't have dependencies to other projects Um, what was one? One example which is useful for sharing dependencies is when you are having a step in every project is the same Yeah, build a template and use it for every project Like the bull step or something else and yeah, so see I provides us really low maintenance time so Normally, we don't have to care about our CI in a month or more time as But not when docker changes their security Images or the way how they seek using docker and docker Yeah, and it's one home for everything. So everyone knows where to find the information and Yes, especially the product management knows what's happened There's everything visible and you know it's afterwards and Yes The user experience this is my opinion the user experience is perfect I love it more than clicking two different tabs because different tools and yeah, and our maintenance is really low So we can keep focusing on building our product instead of struggling with our own infrastructure so Thanks for your extensions and if you have question just ask Okay questions. Thank you. Hi. What are the main benefits of using get lab runners over Jenkins? It's really easy as a you don't have Dependency between branches. So if you're trying something out new in for your For your CI You can do it simply in a branch and your master branch will not be affected of the changes So this is really cool and the CI ammo is really easy to read you have don't have so big groovy stripped and Yeah, you can it's more easier That's my opinion. So and you have the documentation everywhere and don't have plugins Yes Other questions Well forget Can you tell me a bit more about your maven to gradle migration? Because I know maven kind of likes to own everything and do the build the test the integration test You use fabricate to build the docker files and everything and splitting it all up Seems like it might be quite hard work to get your head around Yes with maven we had that were really complicated to Run a task only one task for example only the unit tests or only the integration test you have a Really strong configuration Afford to achieve that and with grade you can simply say okay This tar runs this task and it's only run the test and integration test for example So you don't have to do the steps before we I Don't know what I Don't know what I have the clue Maybe better after after but Do that as a follow-on perhaps any other questions? No Awesome Phil. Thank you so much. Thank you