 All right, welcome everyone to the first platform back end update of 2018 My name is Tao Man as many of you may know and I am the engineering manager for that platform back-end team Today, I'd like to give you an update on what the team has been up to Through the last five weeks since the last update and what we plan to be up to in the next until the next update after this one And then of course will update you on how well those next five weeks actually went compared to the plans If you have any questions, I suggest that you post them to the chat I'll try to take a moment to answer questions at the end of every slide and at the end I'll give you about 15 more seconds to ask questions, but if you want to get an answer quick I suggest you ask quick as well as you can still see the relevant data on the screen So first of all, let's talk a little bit about what we've done in the last five weeks I don't want to go into too much detail for each of these items But I quickly want to mention on December 22nd We released get that 10.3 we had already finalized development of these features two weeks prior to that on December 7th But it's great to see these actually get released and I'd like to specifically call out these four features or three features and a couple of performance improvements that you see listed here with links to the issues and I would like to thank my ride James at first Jones Tiago and from and some other people specifically for these contributions Then on the 7th of January, we finalized development of get that 10.4 Which I'll get to a little bit in the next couple slides and then the day afterwards About two weeks ago to the day we kicked off development of get that 10.5 Last five weeks, we also defined our okay ours for 2018 quarter one all of which are listed here You can follow the link to the okay ours to see some more details And you can follow the links in the slide if you want to read some more as well There's a couple of these that I specifically like to call out as you can see close 60 that from back and book issues This is one of the goals for this quarter to make a significant dent in the backlog of bugs that we have outstanding And this is going to be selected in part because of priority and stuff that a lot of our customers are hitting and then We're also going going to try and address some of the longer standing box Just little 500 errors or exceptions in some pages in the product that we've technically known about for a while But we've never really made time to address them For 10.5 the release we are working on right now. We have 13 of these issues scheduled This may make it sound like we are way, you know off schedule to hit 60 by the end of the quarter the quarter having three months Which means that we need to schedule 20 on average per month We are a little bit below that right now, but that is expected because we also expect to grow in team size over this quarter So while in 10.5, you might see 13 bugs in 10.6 You might see 20 and then in 10.7. You may see the remaining 27 as the team grows and as we gain capacity to actually address these bugs Over these months Then under ship 100 percent of committed deliverable issues each release You can see a little square its square should have been a fingers crossed emoji in case you're wondering Of course, we won't know how well we actually did on delivering these until the end of the month And we're going to do a little retro to see what the percentage is and we're going to collect this data over the quarter to make Sure that after the OCR after the quarter completes, we can see how well we actually did on all of these OCRs That's it for the OCR if you have any more questions the chat is the place to ask them Today we're going to release GitLab 10.4 If you follow that link, you will see that it currently 404 because the blog post isn't actually up yet But later today, this will be happening and one of the contributions that platform made to this is fast SSH Keylock look up in CE. This is a feature that we had had in enterprise position for a while And basically what it means is that when you're pushing over SSH to a repo or you're pooling rather Instead of having to do a linear search to a specific text file that lists all of the keys or fingerprints And the user name that too, which is kind of the old approach and the approach that CE up until now is always used We are going to do this with a quick o1 Database look up now rather than having it be a linear search through this file that grows Every time someone uploads an SSH key into GitLab You might be wondering why did we only contribute one issue or one feature to GitLab 10.4 Well, one reason of course is that the development month for this release Took place from December 7th until January 7th, which included the holidays And during this week between Christmas and New Year's a lot of people ended up taking off So we were a little bit limited in our capacity because of that and the other thing that contributes to this relatively low Output for 10.4 is that during the development month that I just mentioned We had a couple people working on really big features that could take more than one month to complete They were doing some investigative work during the fourth month and only actually You know writing code that will be shipable during the month following it Which is the current month So in 10.5 we'll be seeing some of this labor payoff that already happened during 10.4 But that of course means that significant resources during the 10.4 development month We're not actually puts in stuff that would go into 10.4 itself We were of course able to Include a couple of bug fixes as well in 10.4 And if you follow that link you'll see those and some of the other things we did for 10.4 Of course 10.4 itself is going to contain a lot more stuff than just this one issue Because there's a lot of teams and get that contributed to it. But this is the biggest thing coming from platform backend So then let's look at the next five weeks and you can see from the list here This is going to be a little bit more interesting than what we contributed at 10.4 On the 7th, which is in about two weeks. We're going to contribute We're going to finalize development of 10.5 and then in two weeks after that it will be released Group level seml single sign-on is one of these things that we started on during 10.4 And this is the first iteration to what having seml single sign-on on a per group basis on gitlab.com Which of course is a much requested feature for enterprises or companies that have their own seml instance or their kind of secondary authentication system to be able to use this with gitlab.com rather than having them Have to run their own premises gitlab installation and have that connect to seml on an instance-wide basis We're going to allow this on a group level The first iteration that's going to ship into 10.5 will not quite be feature complete yet It will be behind a feature flag that you can enable using a cookie But the first work will be merged into gitlab during this month and then over in a few months Hopefully we'll be able to present the entire feature for you, which will be per group seml single sign-on on gitlab.com The second one external policy classification control was also one of these really big efforts that we started on last month But that won't actually have anything merged into gitlab until this month, month 10.5 And like I just discussed last time, this is a feature that will allow certain companies in regulations where in in industries where there are really tight regulations about access to certain resources It will allow them to go beyond what gitlab provides in terms of access control and have every click into a project Every click into an issue of project call out to an external service to verify that the user actually has access to this resource And a lot of this is not just implementing the functionality But also making sure that when we are developing features in the future going forward that we don't forget to Build these checks into the right places Because otherwise, of course, we would either end up with a feature that wouldn't work at all in this when this feature is enabled Or we would end up with a feature that accidentally leaks information in this environment Without going to this external External endpoint to check access. So the feature itself is almost feature complete Now we're almost now we're just working not just but we are spending a lot of time making sure that this will not Make development harder going forward Because of course it is quite intrusive to the code base And it will only be enabled for a small percentage of customers So it will be hard for us to find out whether or not a feature we built works or doesn't work correctly in it Except unless we do very specific testing and of course, we don't want to end up hearing from the customer when we broke something We want to be ahead of that news The third thing is going to be implementing git LFS file locking API Git LFS 2.x which launched a while ago 2.0 Which launched a while ago allows file locking through the command line interface If you have a git LFS enabled so that you can have exclusive access to a certain file for, you know A certain period of time to make sure no one overrides your changes that you're making We've had file locking in git lab enterprise edition for a while This was a feature that we would enable in the interface You would browse to a blob through git lab and you would hit the little lock button and then you would acquire a lock on it And then later on you would need to remember to unlock it And git LFS provides the same functionality in the form of a command line interface So that means that we are going to enable the git LFS command line option Of locking files in c and then e we're still going to get the git lab ui around this But it will use the same back end which means that if you lock a file using the LFS command line It will show up inside git lab as a locked file And then if you unlock it from the git lab interface, it will also be unlocked from LFS's perspective I see that john may ask the question will that check be for c e e s e e p e u Were you referring to external policy classification control or something else john if you can clarify I'm happy to respond in a moment and until then I'll move on to the next item on the list Push to create a new project is a really cool feature that has been on the in the bug tracker for a while that we finally made some time for The idea is that if you push to a git url either over ssh or hdp That doesn't point to an actual repository that exists We will automatically create that project for you if you're pushing into your personal namespace Which means git lab comm slash your username slash some project i'll get we will automatically create that project in the on the background Which means that if you're starting out a new project locally in your editor in your terminal Instead of having to then go to git lab and create the project acquire the push url, etc You can just skip that whole step of explicitly creating the project and have this happen automatically the moment you're pushing to the repository Which is going to be really cool because it removes some friction from getting started with a new project The next thing proper LFS support when uploading a file for the web interface This would already plan for 10.4. We didn't manage to complete it then but for 10.5 We're going to tackle this we're going to attempt to tackle this again, and hopefully we will fill it in this time The next one is ability to transfer a single group to another group We've had subgroups for a while as most of you i'm sure are aware But and we also support transferring a project from one group to another or from someone's personal namespace to another group But we don't specifically support moving an existing group into another existing group as a subgroup yet This was actually a feature that myra worked on in her tech interview when she was a technical interview as part of her Interviewing process when she was applying to get that as a developer and myra also You know opened up some time to finish this metric as that she had started them That's going to be a very nice feature That's going to be make it easier for users to migrate to a subgroup subgroup based workflow Instead of having multiple groups all at the root level a nice thing about subgroups One of the nice things is that you can have Access flowdowns if you add someone to the main gitlab organization for example Who will automatically gain the same level of access to gitlab slash development gitlab slash marketing etc As you can imagine this is applicable to a lot of company organizational structures And it will simplify access control and will simplify sharing and that kind of stuff I see that john clarifies checking to see if that person should have access at every click it looks like ee but i want to know if it's ee s ee p or ee um I think it's going to be ee p. I hope that mike bartlett is in the chat because he will be able to Clarify. Yeah, exactly. It will be premium. Oh, yeah. I guess we're not calling it ee p anymore It's just premium now, but that will be announced in the team call in about 20 minutes So until then i'm still going to do it wrong. Sorry about that um, so yeah premium um next integration test for backup restoring gitlab qa We've had this really cool project called gitlab qa for a little bit What it does is it allows you to do kind of integration testing not just of the rails application That is gitlab but the entire virtual machine that you get when you install on the package That means you've got your postgres you've got your your your you know the main gitlab application But that means you can also test these kind of things that require an actual vm to be running and verify that these are working as expected So for example, you could backup and you could create a backup for x For a complete gitlab vm with everything on it the data in the repositories and the data in the database You could create this backup and then restore the backup and then verify that the vm you end up with after we restore Doesn't need have the same data inside it that the vm that did that you started with This is kind of hard if you're testing contained through gitlab to rails integration tests because then you can really only Minic requests and make sure that the request returns the stuff that you're expecting But if you actually want to do stuff against the whole vm, that's something that gitlab qa enables you to do Of course, we do have backup restore integration tests inside gitlab rails already But if something somewhere goes wrong in omnibus configuration, for example, or in setting up the vm We currently don't have a way to catch that and these gitlab qa tests will enable us to be ahead of those kinds of mistakes Um, and we have a lot of other stuff for gitlab qa plans and I know that a lot of people my themes are adding stuff to Gitlab qa and this is going to be platform backends first contribution to make sure that backup restore will never end up breaking In some way that we couldn't already catch using rails integration tests Of course, there's a lot more that we are working on this month And if you follow that little more link you will be linked to our issue tracker or you're tracking all of those issues If you have any specific questions about any of these issues I suggest going into the issue itself and asking there or of course ending it in the chat while we're still Here another thing that the platform backend team will be working on in the next five weeks is automatically billing newly added users on gitlab.com Not every one of you may be aware that one of the responsibilities of the platform team is not just the platform base the platform functionality inside to get that application But also some of the applications that we use internally to for example allow users to pay for gitlab.com subscriptions The customer app is one of these and one of the things that we are adding to this during this Upcoming five weeks and that we have been working on for the last two weeks Is the ability to automatically build newly added users on gitlab.com This means that if you have a group which starts out with 10 people when you You know create your gitlab.com subscription and then you add five people over the course of the month That means that the next month we will automatically be billing you for those extra five Users and I think will also be retroactively applying You know if they were added halfway through the month we will retroactively build and have a month of subscription for those five users This is not something we had before then we would need to explicitly up the number in our backend system, but now this will be automatic as well So that's what we're going to happen during the five months and then after during the next five weeks And then at the end of it we are going to kick off development of gitlab 10.6 on february 8 As you may know by now we usually only decide what's going to go into a release a few days ahead of that february 8 So if you want to know what's going to be in gitlab 10.6 I suggest that you join the public kickoff which will take place on that february 8 and hopefully by then I'm pretty sure by then we'll know exactly what's going to be in 10.6 That's everything I had to prepare for today If anyone has any questions I'm going to give you about 10 seconds to enter those into the chat And if nothing shows up then I wish you a great rest of your days If you are a gitlab, and if you're not a gitlab, then I wish you A great rest of your day whenever you end up viewing this through the blog Thanks for your attention everyone I think the 10 seconds are over by now and have a great rest of your days And I'll see a lot of you in the team call a few moments