 Hi everyone, my name is Marin and this is a functional group update for the build team. We'll go quickly through the OKRs that we had in Q4 and Q1 for this year and I'll just quickly introduce some team changes and we'll do questions in the end. First of all, we have a new hire starting from January 1st, Ahmad Hafan joined us as a build engineer and he will be helping us out at the beginning with the helm charts. Our hiring plan also allows us for a one-way hire in 2018 and that should be just enough to get our projected goals done this year. So I want to go through OKRs now because we are at the start of the year and I want to present what we achieved in 2017 Q4 and what we plan on doing in Q1 this year. So someone is unmuted, I would appreciate if you could mute yourself, okay I cannot see who that is but I'll move on. So one of the tasks that we had was decreasing the build times from 60 minutes to 30 minutes. Why was this important for us? Every time we need to try a change out that would mean a developer engineer would have to wait for 60 minutes plus to get their changes tested from end to end basically. We invested a lot of time there and we managed to complete it 100% and we have our builds running under 30 minutes. Just to give you a bit of a, I'm still hearing someone, can someone take a look who's unmuted? Might be Haydn. Okay, I don't hear it anymore. Anyway to give you just an overview why this was important was we also moved to GCP where we have a separate project only for build machines and I've looked at the numbers, so the cost and the amount of machines we created in January. Every executed package build cost us around 2 euros. Doesn't sound that much but we have thousands of builds every month. What is really interesting there is that only 6.8% of all of the package builds were release related meaning they were for public consumption. Everything else was created during our testing. I don't really want to give the full numbers that might be a sensitive topic there but just think of the amount of time we saved by achieving this OCR so I'm really proud about achieving this one. Next OCR we did was create an integration test for Metamost. Why did we want to do this? Well we have this integration out of the box in the package with Metamost and during 2017 this integration broke a couple of times either due to changes in Metamost or changes in the package or changes in GitLab itself. So we decided it would be nice to extend our GitLab QA project a bit and add this integration test. This was 100% completed and I don't know if it's because we didn't break anything or because we have the test but we haven't seen an integration being broken at least from the package side. So I think it's a beneficial change that we achieved here. The next OCR was establish baseline metric for install time and so on. We only did 10% of it. Basically the late start on this issue I think something like mid-December meant that we didn't even have the time to properly discuss what the OCR is. So this was a complete miss on our part and something that I think was a good lesson for us. The next OCR was build GCP deploying a mechanism on Kubernetes for the migration. I would say even in the best of cases this was very much a moonshot to achieve in one quarter especially considering that we started in November so after everyone returned from the summit. That meant we had like a month and a half to do a project that changes the complete deployment strategy of GitLab. So to say this was ambitious it is an understatement but we still managed to do around 30% because by the end of December if you struggled a bit and if you stumbled upon certain things that we wrote you would be able to deploy GitLab using the charts. We did learn a couple of things. So let's see what we actually learned. In Q1 this year we want to upgrade some of the internals of the package. That might not sound that complex but it requires a lot of testing and it's important to stay up-to-date to the upstream changes of course security and it brings a number of changes that we could use to optimize the package. What we learned this time around though was start on time. So we started with this one and we already have 50% of it done. We are up-to-date with the upstream omnibus and we started working on upgrading the internal omnibus GitLab chef. Next thing measure upgrade installation time between two GitLab versions. This one might sound familiar to the one in Q4 2017 and it might sound like that because it is exactly that just worded a bit differently. We do want to know how much time it takes to install GitLab between versions. So right now what we started doing is we started off by creating an epic a small thing but we started working on the actual issue discussing the ideas we have and I think the work already started even though it's supposed to be starting next week. One of the things that we still do manually and it's taking us a lot of time is checking up the libraries that we ship for security vulnerabilities. We want to make a plan so this is establishing a roadmap so creating a plan how we can automatically scan our package and check out whether a library has a vulnerability. This is still being worked on as discussion just yet but we are planning to leverage more of the newly acquired security scanning knowledge that we have starting from yesterday I think. So we'll be talking with that team pretty soon about that. And now we defined another OCR that sounds really familiar to one of the old ones but we now have a clear idea of what we want to do. We want to have the Elm chart in alpha and we have a solid plan on how we can accomplish that. What I think helped in this case was that we after we set some base in Q4 we finally knew what we were up against so we could actually define it a bit better. And what we're also doing this time around is we're doing weekly demos where the presenter is testing all the changes that are made by following a script. If you're interested you can see the record is in the Google Drive and also you can join the demos if you want to there on Friday an hour before the team call. That's about it from my side. I'll take any questions that we might have. Thus this means that every Docker container I triggered costs two euros probably a bit more Joshua than that but the package itself that has to be built for you to boot up a container definitely did cost two euros. Someone says it's always easier to add a test to an existing suit. That's correct. Awesome. I don't see any more questions. Thank you very much for following and see you at the team call. Bye.