 Alright, welcome everyone to this edition of the five-weekly platform backend update. My name is Dao Man. I am the platform backend lead at GitLab and I will be walking you through what we have been working on the last five weeks, we being me and my team and what we are planning to do in the next five weeks. So first, in the last five weeks, we started development of GitLab 9.4 on June the 8th. For those who are not familiar with the process, we have a release every month until the 22nd and we try to finalize the release, all the features that are going to go into it, etc., on the 7th, which means that on the 8th, we are already starting working on the release that will be after the release of the next 22nd. It's a little bit, can be a little bit confusing, but basically we have a monthly schedule for development and for actual releases that line up two weeks and then the new release already starts. So that's what we started doing on June the 8th and on June the 22nd, a couple of days ago, we released GitLab 9.3 with such notable things as a more robust backend for repository pool mirrors. This is an enterprise edition feature where you can set up your project to pool from another remote repository to automatically get any of its updates. It's a way of mirroring a remote repository. The way we used to do this update was relatively naive. We just had a automatically scheduled task every, you know, so often every couple of hours or whatever that would pool from this remote mirror, but what this meant is that if you had millions or thousands of these mirror projects on your GitLab instance, there would be a huge spike of all of them trying to update at the same time, which could actually negatively affect the performance of the GitLab web application because so many resources were being used at the same time by all of these remote mirror pools. Now, thanks to Tiago, we have a more robust backend for this that kind of spreads all of these updates out over time so that every project still gets updated as frequently as it did before, but fewer get updated at the same time as the others. And there's also a mechanism in there that will punish a project that's failed, for example, so that a project that failed to update will not be updated without reason every couple of minutes and it will fail and fail and fail again. So this is definitely going to make a big difference on GitLab.com and even on your smaller instance, you might notice an improvement. Another thing we worked on is improved audit logging. This is an enterprise edition feature that we are spending, investing some more time in this release and upcoming releases to improve the audit logging functionality. The first thing we did is add a mobile page for all of the server-wide audit events, which means all of the access-related events that happen in all of the projects on the GitLab instance. By the way, I think that someone from Git, I think it's Andrew, who did some feedback. If you could mute, that would be great. In any case, improved audit logging. And in future releases, we're also going to look at what we are actually audit logging for each project and for each user and we're going to see if there's any holes there that we want to fill, more things we want to log to make this even more representative of everything access-related that goes on on the GitLab instance. Thanks, James, for working on this for 9.3 as well as for 9.4. Then we have improvements to subgroups. Subgroups is a feature relaunched with GitLab 9.0, which is already three months ago. It works really well, but there were some things, especially in the UI that were not as polished yet as they could be. And Dimitri and Alfredo spent some time on this this month to, for example, improve the project index and make these nested projects actually display in a nested hierarchy fashion where you can collapse and expand individual levels of the hierarchy and you will see all of the projects under or all the groups rather of the level that you just expanded. Then we also have more internationalized pages and more languages. Last release in 9.2, we started with internationalizing the cycle analytics page. With 9.3, we have added the project repository page, which is pretty much the page you see when you browse through any projects, kind of the project home page. And we also have some other pages that have been getting some internationalization improvements on them. And we were really happy and a little bit surprised to see how many people from the community took up the effort to translate GitLab into their own language. GitLab is, you know, by far not completely internationalized yet. So at this point, there's only one, two, three pages. And we will reflect these internationalization changes, but community members have already contributed languages such as multiple versions of Chinese, Bulgarian, Portuguese, French. Of course, we shipped with Spanish and German, but it's really great to see that people in the community are already helping us out getting GitLab translated into more languages. The main menu at the top, more context asks in the chat. I don't think that's been translated yet. If you think it should be prioritized, then reach out to Mike Bartat. So these are a couple of the things that the platform team worked on for 9.4, of course, for 9.3, sorry. Of course, there's a lot more that we did. And if you hit a little more link in the, in the spreadsheet, in the, in the slideshow that will be shared, you will be able to find this whole list. And of course, if you check out the GitLab 9.3 blog post, you will see a lot that everyone in the company worked on instead of just the platform team. 9.3 was another great release. And these were just a couple of the things in there. But if you look there, you will find many, many more. So then in the next five weeks, we plan to first enable Elasticsearch on GitLab.com. This has been in my functional group update for the last two times, which means that for 10 weeks already, it hasn't been done. The reason for this was that the production team, of course, has tons and tons of things going on. And they did not have capacity at that point to put resources on, you know, setting up this Elasticsearch cluster. Et cetera. But with Victor Lopez joining just a couple of weeks ago, he will now be working on setting up the Elasticsearch cluster for GitLab.com, which means that in due time, everyone will get access to more performance search on GitLab.com, including search using such features as and and or and negation, all of which are supported by Elasticsearch, but not by our simple SQL based search, which is only enabled, you know, which is enabled by default, but which can be overridden if you enable Elasticsearch, which is far more powerful. What this will also bring us is project-wide, as well as global code search. We already have project code search. If you are, if you don't use Elasticsearch, but with Elasticsearch, GitLab.com, and anyone else using Elasticsearch, we'll get global code search as well, which will be great. And you can hit that little working on it link to see exactly the status of the work that the production team is doing on this. Jacob asked, can we use it for issues searching on the tokenization page? We absolutely can, although right now, it is not hooked up to Elasticsearch yet, but we can definitely look into hooking those up in the future. Sean, the government just partial meshing, camel case, global code search. Yep, exactly. Those are some of the things that Elasticsearch will bring. So then in the next five weeks, we will also finalize GitLab 9.4 in July 7th and release it on the 22nd, which means we'll finalize it in about two weeks and release in the month, which will have such things as EE behaving as CE when no licenses entered. This is not specifically interesting to existing users on GitLab, but the goal here is to make it easier to move from CE to EE by allowing anyone who is currently only interested in CE to still download the EE GitLab package and just use it as if it were CE when no licenses entered, which means it will be easier for them to, if they at one point find one of the EE features interesting, upgrade to this without having to migrate their entire GitLab instance, etc, etc. And of course, from a business perspective, it will also allow us to add some banners or informational pages with what people are missing out on by only using CE and not EE, because we find that a lot of people currently are using CE and don't even know what actually EE has to offer them. And once we tell them about what EE has, they were like, wow, that's really cool. I didn't know GitLab could do that and they are interested in buying, but they were not aware of this functionality at all because they were just browsing CE and not being exposed to this EE functionality. So this is something that for GitLab 94, we are spending a lot of effort in basically going and finding every EE specific feature in the EE code base and adding checks around it that's verified that the feature is actually enabled with the license and if it isn't falling back on the CE behavior. So we have three people on this this month, Bob, Thon and Nick who are going through every single EE feature and introducing these checks. The second one is also related to this which is the ability to directly get a trial license from EE. Right now, if you want a trial license for EE, you have to browse through the customer portal, you have to get the trial there, you have to manually upload it into GitLab EE and this is kind of a cumbersome process and we're going to streamline this by adding some options inside GitLab EE itself and we'll communicate with the customer app in the background or through some kind of redirect flow and we'll get you this license so that you can get up and running with EE and the trial license right away. Then we are also working on the improved GitLab.com purchase flow. This is mostly interesting for the GitLab.com plans that we have already rolled out for CI build minutes but that we are also going to roll out for EE specific features which means that if you want EE premium functionality on your GitLab group, on your GitLab.com group or your GitLab.com username space, you can go through the customer app and pay for this and then you get these features and improving this purchase flow will be really good here because it will be a lot easier for people to actually go about purchasing one of these GitLab.com plans. Of course, we're not only working on things that benefit the business, that benefit discoverability of features, we're also going to bring some features to CI and EE that will directly affect our developers' experiences with GitLab. Our developers in this case being developers who use GitLab, so pretty much our customers and everyone else who uses the customer, the community addition. One of these things we're going to do is projecting commits with missing LFS files. This could arguably seem as a bug that we don't currently have it, but it's something we're going to implement and we're going to fix. And there is a little more link there which will show a lot more things that the platform theme is working on. There's also a number of things that the platform front-end theme is working on but since this is specifically the platform back-end update, I'm not going to cover those, but if you check out the more link and you adjust the gitlab.com issue labels filter appropriately, you will see these as well. And then on July 8th, after we have finalized GitLab 9.4, we'll start developing GitLab 9.5. Since there are still two weeks between July 7th and July 22nd, this is also the period where we will be working on fixing any regressions in GitLab 9.4. We find we will try to get it up and running on gitlab.com ASAP after the 7th, which means we have about a two-week timeframe for us to find any small issues we didn't already catch in development, get those fixed before the product actually goes out to customers. So that's what we're going to be doing as of July 8th, and like I mentioned, we're going to be working on new GitLab 9.5 functionality as well. Since we only finalized the plan for a new release a couple of days before that 8th, I don't exactly know yet what's going into GitLab 9.5, but that's something I will talk to you about in the next Functional Group 8.40 form backend team. Let me have a quick look at the chat to see if there's any questions, because this is the end of the presentation. I think Mike Bartlett already answered some. If you have any more questions, feel free to ask them in the general general or anywhere else. And with that, thank you so much for your attention, and I will talk to you in five weeks.