 Right, welcome to today's Platform Backend Update. This is the 6th of November, 2017, and my name is Dao Man. I am the Platform Backend Lead at GitLab for all of those watching along at home who did not know yet yet. So today, I'm gonna talk to you a little bit about what we, this team specifically, has been working on the last 10 weeks. Normally, we have one of those every five weeks, but five weeks ago, due to poor internet connection quality, I couldn't do the update. So I'm gonna go over everything that happened in the last 10 weeks in kind of a bird's eye overview. First of all, we released GitLab 10.0 on the September 22nd. Of course, there were a lot of notable features in this release that you will be able to read a lot about if you follow that GitLab 10.0 link, if you have the presentation open. Two of the things, or at least one of the things I wanted to specifically point out that our team worked on is object storage for LFS objects. This is something that was built by James Edwards-Jones. And basically, it allows you to use as the name describes, object storage, for example, S3 or an S3-competible storage system or anything else that is supported by carrier wave, in fact, to store these LFS objects. And this means that you will not have to need to store those on your local machine anymore. And especially if you have a lot of GitLab instances that share file storage, this will take all of that traffic away from your NFS, for example, so it will also increase. It will decrease the load on those machines too. So it will be a performance improvement and generally an availability improvement. There's also various performance improvements for that went into 10.0 coming from the platform back inside of things. And I wanted to specifically thank Tiago, Nick and Ruben who spent a lot of time on those kinds of issues for this release. And you can follow those links if you want to know specifically what we did. Then on October 2 and October 9, we welcomed a couple of new people to the team, specifically Fran, Brett and Myra. Brett, about two weeks ago, moved on to the GEO team already, which is working on making GitLab GEO generally available this month. And GEO DR after that with Fran and Myra are on platform and they have already worked on some software 10.2 that you will see in the next slide. Then on October 22, we released GitLab 10.1 with a couple of features coming from platform. First of all, merge requests between forks. Of course, we've had merge requests this feature forever where you could create a merge request from a fork of a repository back to the original, the canonical source. But something that we didn't allow until now is merge request between forks from one fork to another. For example, when a colleague of yours suggests a change to the main code base and you want to suggest a change to their change, you can now create a fork of the main repo and you will still be able to edit that person's merge request or that person's branch and submit a change back to that. And this works very easily. If I open a merge request by someone else and I hit the edit button, it will automatically do all of the pooling behind the scenes to make sure I have that other person's code. And I can suggest changes that will then go back into their branch in their fork. And then when they accept my merge request, it will automatically update the merge request that they had created back to the original source. So thanks, Bob, for working on this for 10.1. Next, we have LDAP group sync filters. We've had LDAP group sync for a while where you can set up a specific LDAP group to be synced with a specific GitLab group so that everyone in that LDAP group will automatically gain access to those projects that fall under that group inside GitLab. What we have added now is the ability to not have group sync depend on a specific group name but have it depend on a specific LDAP filter which might look at other attributes of the LDAP person to decide whether or not they will have access to the GitLab group in question. So for example, you can filter by employee type contractor or role developer or something like that instead of it having to be an existing LDAP group. Thanks, James Lopez, who spent a lot of time working on this. Of course, there was UX and Frontend Evolved too but those will have been covered in the Frontend update. Rejecting on Signed Commits is the third major feature for 10.1 that platform contributed which adds a push rule as we call these where you can say that your project will only accept Signed Commits. So these are commits that have a GPG signature attached so that you can verify that no one's pushing in code that isn't signed to have been committed by a specific person. And this can be configured on the project level but you can also on the global instance level set this setting and it will automatically be enabled for every project on the instance. Next, we have verified secondary emails. We have had secondary emails for a while and these are used, for example, to link commits to your user profile by checking the commit author email or committer email but these couldn't be verified before now. So that's what we added in this merger question, this release 10.1 which means that we can now also use secondary emails to determine whether or not a GPG signature is verified to belong to the same person who committed that commit. Before we would only treat commits as verified if they were actually created with the same email that the GitLab user has set as their primary email on their profile because this is the email that they signed up with. So the email that has been verified or confirmed already and now any email can be verified. So this both enhances GPG and it's just nice in general to know which emails are verified to belong to certain people and which ones they just randomly added to their profile even though they weren't actually there on. So that's it for the last 10 weeks. In the next five weeks, we plan to first of all finalize GitLab 10.2 on November 7th which is tomorrow and release it on the 22nd. Some of the notable features that platform builds are automatic rejection of commits with missing LFS objects. This is something we started working on a couple of months ago but the summit, you know, tell in that period and there were some other things that kind of delayed it a little bit but for 10.2, this is finally gonna ship along with this automatic pruning of unreferenced LFS objects. But this means it becomes a lot easier for you to enforce kind of the integrity of the LFS large file storage that is attached to your project. Instead of missing files and people checking out the project and then getting all of these not found errors when they try to open certain files. To prevent that from happening, you can now ensure that when a user pushes, we immediately validate that all of the LFS objects that are referenced in their push are actually already known to GitLab. And the second of course has to do with file storage which means that if you push an LFS object but then you delete that branch or you force push to kind of remove that commit again, we will eventually clean up that LFS object. This is sort of garbage collection. Right now that only happens when the actual project is deleted entirely which means that if you have a project that does a lot of rebasing and rewriting of history, you will probably have some LFS objects that are still on storage that could have been cleaned up by now and this is what will start happening starting with 10.2. Next we are adding more auto events around the group and project actions. For example, you know, removing or moving or adding people to a group or project. These will be logged and these log audit events will be available from the admin area if you are an admin of the instance. And also if you go to the project settings, you'll also find a page with all of the actions relating to this project specifically. Next, we are adding another push rule kind of that will kind of work in unison with the one I just mentioned that we shipped in 10.1. This is requiring commits to be committed by the pusher. If you have an environment where you wanna be very sure that all the codes someone pushes is actually written by them or at least signed off by them, you can enable this feature and you will not have people pushing in other people's commits whether intentionally or accidentally. Because of course this can be used by attackers to trick someone into pushing their commits into GitHub or into the repo with confidential information that you might have. And with 10.2, we are giving you a way to prevent this from happening. We are also finally getting rid of private tokens. We're not getting rid of personal access tokens. There will still be a way of course to authenticate to the API using a token. We're getting rid specifically of the private token that used to be exposed in your profile on the account page that used to be used in a couple of URLs inside the GitHub web interface for example, the RSS feeds. Because this token was pretty much all powerful and if it leaked or for example, it was stolen using XSS, that meant that everyone could now interact with the API as if they were you. So we are getting rid of private tokens. They will be removed from the profile page or removed from the API user endpoint and all of them have been converted into personal access tokens in the background. So if you've been using them, they will just continue to work as they did, but they will not be exposed in the web interface anymore and they have now been moved to the personal access tokens page where it's still called private token. Next, we are getting improved performance of activity feeds. There's just one thing that I wanted to point out specifically because a lot of you will probably be opening your GitLab to activity feeds all the time when you open the dashboard or you open a group or you open a project. And the time that it takes to load this list to kind of see what's been happening since the last time you saw GitLab is gonna go down significantly. So there will be a nice performance improvement. And of course, there's a lot more that's gonna go into 10.2. Some stuff that the platform backend team worked on and of course, tons of things that were worked on by other teams. You can find that if you follow that little more link which will take you to the issue tracker with the appropriate filters applied. So that's tomorrow, November 7th and all of these features are either already merged or will be merged very shortly. And then of course, after that on November 8th, we will kick off the development of GitLab 10.3. We are still finalizing what exactly the theme is gonna be working on for 10.3, but I invite you all to join the public kickoff which I've also linked to so that you can be the first to know what's gonna be in GitLab in a month and a half time. And of course, if you have any questions, you can ask those then as well. So that's it for this platform backend update. If you have any questions, you can add them to the Zoom group chat. Of course, if you're watching this live, if you are not, then you can find me some other way. I think this is gonna be on the blog and I'm sure there's ways for you to contact us if you have any questions about any of these issues. With no questions having popped up in the Zoom group chat, I would like to thank you for your attention and I wish you a great rest of your day.