How we run the Umbraco Open source project

Alright, can everybody hear me? I'll try not to mumble too much today. I'm known for mumbling. Hi, I'm Sebastian, I'm here to talk to you about the secret sauce of Umbraco, or the running DVD commentary, or the look inside the kitchen of Umbraco. I am the project manager of the core of Umbraco, which basically means that I try to help our team get Umbraco out on time when we say we are releasing Umbraco and of sufficient quality. I try to help people focus on the right things and stop bike shedding and stop deciding which color, which tint of gray the one line should be. Maybe we should move on. And get this thing out of there. I also do a little bit of developing myself. I like fixing bugs in Umbraco. I am a very mediocre developer. I know a lot of things about... I know very little about a lot of things, so I can do the top layer. And then I have my team who can help me. Like, oh, how do you do this? And how do you do that? And they are really good at that. I am also... I think this description of me on the website was community steward. So I think what that meant was that I am trying to get our Umbraco community going again. So last year we changed it to the new layout and everything. It is very much focused on forms and packages now. And we want to get the whole community feeling back where we see blog posts and Twitter feeds and things like that. So we are working on that right now. I know, is Handy in the room? Nope. Handy is helping me a little bit with that. So hopefully we will get that up and running again. And people will start blogging again and tweeting more about Umbraco. Which would be really cool. Other than that, I do Umbraco training. So usually what used to be called a level 2. It is now like one day courses. Who has been to Umbraco training before? Oh, very good. All of you have it at once? You should come. Especially to Denmark. It is fun. Or if you are in the UK, you definitely should go to Mark and do the level 2 training or whatever it is called now. Other than that, I do a lot of things about everything. So I like... So when I started out at Umbraco, I really hated that we couldn't just check out Umbraco, build it and run it. So I have been doing that automation. Blake has seen that now. So we will talk about that later. I also hated that people had so many troubles upgrading all the time. For me it was super easy. I am like, yeah, you just do this and this and this and compare this and that and that. And then put some SQL in and you are good to go. It is really easy. So I try to make that easier for everybody instead of just for me. And hopefully you should have experienced that now. If you use NuGet, whenever you update package in Umbraco, it should be way, way, way easier. Way better than it was a few years ago. Recently I have been focusing on security. More about that later. As I said, I work on Hour. I do a little bit of work on Forms. I help Warren with code reviews and things like that. I have done a bit of work in Courier. I have been working a lot on Umbraco as a service for the past year and a half. So I have been a little bit less visible as a project manager for the core. Because I have been focusing on getting that up and running and making it perfect. If you are interested in Umbraco as a service, you should go to the workshop next door. And as I said, I am just a casual developer. I like making things and making them work. I am not the person who likes to make the unit tests and put in a layer of abstraction to make sure that the IOC works perfectly and things like that. I leave that to my lovely colleagues. Speaking of whom. Oh, this is the agenda. I am going to tell you a little bit about what our team is like. The daily grind. What we do on a day to day basis to progress the development on Umbraco. A little bit on security. Contributions. If you want to help make Umbraco better. Blake is going to show you her first pull request. And then we will build and release Umbraco. We will tell you a bit about that. So team. We have Shannon who has been on board for a long time now. He is from Australia. Moved to Denmark for a year and a half to help us out over here. Shannon is the CTO now. So he makes the technical. He decides the technical direction of Umbraco. We don't have titles but he is technically the CTO. We have Mesh and Simon. They are pretty new to Umbraco. Started I think a year and a half ago. Mesh is our Angular wizard. So he knows a lot about doing stuff in Angular. He is also very good at UX. Together with Simon who used to be our resident designer. But now is more involved in the UX as well. So they are responsible for the new document type editor for example. They have done all the testing and all the refining and things like that. Doing an amazing job there. So Simon is moving from being just a designer to doing UX and frontend stuff. Stefan. Is Stefan here? Right there. There you go. Our resident crazy French guy. Yep. He is our pie in the sky. A big thinker. He wants to do a lot of things and everything is broken. So he has been helping us make everything unbroken. It has been good. You have seen him yesterday. He was talking about the new cache that we are putting in. Which is a big project. Which has been iterating on for a long time. And it is going very well. And other than that he helps out with whatever issues we have in the core. Warren. We recently rehired Warren. Beginning of the year I think. You might know him from something called You Hangouts. Which is a weekly, well it used to be a weekly video podcast that he did on YouTube. Inviting a lot of interesting guests who have something to show related to Umbraco. He is bringing that back after Code Garden. So it will be fun. Some of you have actually been on You Hangouts. I see people. Well recommended. If you are into Umbraco then definitely go watch the archives. There is a lot of good interesting sessions in there. And finally Klaus is our resident courier guru right now. But he will also be helping out on the core. Building, fixing bugs and building new features and things like that. He is also pretty competent at Angular. We have like 50% JavaScript and 50% C sharp there. There we go. Oh and Warren is not just for You Hangouts. But he is also doing Umbraco Forms by the way. You have a question? Oh you were going to say that is what he is doing. So he is doing Umbraco Forms which is part of what we call the core of Umbraco now. So Courier and Umbraco Forms. All the products are not one thing. But we do, what is that, what do you call it? We review each other's code. Oh and me. Oops. I do stuff as well. So what do I do? And what do we all do at Umbraco? So there is transitions. I didn't know. It is going the wrong way. Oh well. So day to day most of the times we wake up in the morning and we have a look at what interesting stuff has landed in the issue tracker. Whatever simple issues there are we can usually just figure out and see if we can replicate the issues. And then we can possibly fix them. We have a look at GitHub to see what happened to pull requests. Some people like to work in the evenings or some people work in Australia or the US. So we check out what the commits are to the core. What new things came in. If the builds still work and things like that. I personally check out. I am subscribed to the Google Alerts or something like that where you can subscribe to a keyword. I just subscribe to Umbraco and I get emails every time anywhere on the web Umbraco is mentioned. So I see a lot of Stack Overflow posts and forum posts and things that go on just to get a general overview of what is happening in the Umbraco world right now. And maybe I jump in because something is broken or whatever. Or somebody is wrong on the internet. That happens a lot. So yeah, I try to correct people in a hopefully nice way. And see if they can correct their ways. Of course then we also have support plans. So we have something called Zendesk which sometimes we get some tickets and we need to solve them. A lot of the times out of those tickets, out of the support requests come new documentation. Because we figure out, oh yeah, this question is being asked again and again and again. So we might as well document it. Load balancing is one of those things. If you don't follow the documentation exactly, it really will not work. So please do what it says. Now there is a new document from Jeven. So that will be interesting. We need to compare what they did and if that is the way to go. It is the way to go by the way. Because they are good. So then we do sprints. We do scrum. But not really scrum. We started doing scrum for the US project. And we started to try to do it officially, the official way. We realized for the Embraerco project there are so many inputs. So many things happen. A lot of support. A lot of tiny little issues that come in there. So it wasn't really feasible to say, okay, we are going to do this in this sprint. And we are going to make story points for everything. It was way too much work. So we are doing scrum but we are just doing two-week sprints. We pull in stuff and we know that there will be a lot of unscheduled issues that will pop up. And that is fine. So every other Monday morning we gather in lovely Onza here at the HQ. Have we all been to the HQ? Some people? Good, good, good. We start the engine there. It is a lot of diesel. No. It is actually really cool. I have seen it run only once. But it is very interesting. Things are spinning and everything. So the sprint planning meeting is very ad hoc. When we see stuff in the tracker where we think, oh yeah, we should fix that. We just tag it as consider for next release. And then we go through whatever we find in that list on Monday mornings. We have a look. Recently we have been having a look at really old issues. So go all the way to issue number 21 and see if we either fixed that already or if we can do something about that. So that we can not just the new things get fixed but old things get picked up as well. There is another thing we are... Oh yeah, of course, anything that has a PR on it or anybody has posted some code. It is really usually really easy to start accepting those things. So we make sure that we take those on board immediately so that the pull request queue gets cleared out. We have not been doing that for a long time. And now we are getting used to doing that. So your PRs might actually be accepted quite quickly. Great. And then after that, after we are done with our sprint landing meeting, we have a sprint document that we actually post on our Umbraco. That is updated every week. I usually tweet a link to it. And then you can actually see what we are actually trying to achieve in that sprint. We usually have one big sprint goal like release new version of forms of new version of Umbraco. That we try to get to. And we usually don't get... It is always funny like every Monday we are like, did we achieve our sprint goal? Yes, but there is still 18 open issues. Okay. We had one week recently where we got really close. So we need to follow that format and make sure that we actually finish everything that we planned on. But as I said, we have so many like incoming things that it is hard to actually plan for stuff. So that is okay. So far we are at least making cool Umbraco releases. Who has downloaded 7.5 beta yet? Does it work? Yes. Cool. Yep. And then we start working. We have three columns in our... I should actually show that because nobody can see that. Unfortunately, we can't open the Agile board open for just everybody. For some reason. But we have three columns over here. I will show you on the screen. Utrecht's permissions are horrible. So it is impossible to show this right now to everybody. We are looking into how to make that better. So we have open, in progress, review. If the review is okay, then everything goes to fixed. If it is not okay, it goes to reopened. We assign things back to the original person who was actually building it. And then we can fix these things. So it looks like we are good. This sprint was 16. Everything was fixed. But it is a bit fake because we moved everything else to sprint 17. So... Shh. Don't tell anybody. As you can see, we have... So red is Umbraco. Green is forms. We sometimes have some contour stuff in there as well. But at least we are following this pattern now where we actually review each other's code. And then we can have a look at does it look good? Does it work? We actually test stuff. How do I get out of this? Yep. There you go. Yep. So at the end of our two weeks, we do demos. If there is just bug fixes, it would be hard to show a demo of that. It is like, no, it doesn't work. And look, on the new build, it does work. But if there is new features or something that we have improved somewhere in the workflow or something like that, we usually demo that to everybody. And we do demo days for all of our products. So, Umbraco's service and forms and courier as well. Or even if someone found something clever, built a tiny little tool to automate something, we just show it so that everybody in the company knows what's going on. Recently, Messe and Simon showed their... Well, they didn't show it, but they had a style guide for working in the back office. So, making sure that everybody... Everything looks consistent and works consistently. So... It's confusing that this thing is going the wrong way. So I'm going next, but it's going sort of previous. Oops. Let's not kill my laptop. Does anybody have a tissue? It'll be okay. Some things that you might not be able to see... Thank you very much. Oh, that's not... Don't press too hard on the keyboard. Yeah, that'll be fine. Just do the screen if you want. Thank you. Some things you might not be able to see. I'm not sure what is publicly visible for you guys on the issue tracker. But we have tags there. So some of them are like Up for Grabs. I think those are publicly available, which helps people find things that they can do if they don't have any inspiration to help us out. But they want to help us out, go have a look at the Up for Grabs search tag. The other one I mentioned is Consider for Next Sprint. So that's anything we see in those two weeks that we're working really hard and we're like, we don't have time to do this right now. But in two weeks, we can consider that to be fixed. PR is when somebody has actually submitted a pull request. And we're always very happy about that. And it's also not just for us to see what's going on, but it's also nice to have a look back through the history. And do a search on these and see if we have an up-going graph or a down-going graph for PRs, for example. One of the more important things on this thing is the state of the item. It says Submitted on this item, which means that one of us has probably read it. We read all of your issues, by the way. Sometimes I get like, hey, did you see this issue? Yes, I really did see your issue. Don't worry. I just didn't have time to follow up on it yet. So we read everything. If I can see from the issue immediately, oh, yeah, that's totally, yeah, that's broken, then I change the state from Submitted to Open. So we actually know that it's something that we really should fix at some point. So that's Submitted versus Open. I talked about Consider for Next Sprint. Due Inversion. So we have some important fields here as well. Affected versions and Due Inversion. So the affected versions are really handy for us to know. It's like, oh, yeah, I tested this on 736 and it doesn't work. Sometimes the answer is just, oh, just upgrade. And then if we do find that it's an issue for all of these versions, then we can set it to Due Inversion. That usually means that we are going to try to fix it for that version. Sometimes we don't get to it on time and we need to move stuff. Oh, my Bitcoin is now $750. Thank you. Don't step in now. It's really high. Yeah, that's our Due Inversion. So we try to fix it. It's not a promise that it's Due Inversion, but mostly we try to get stuff out in the next version. As I said earlier, recently I've been focusing a little bit more on security. We get a lot of questions from people like, do you do any regular audits or do you have any security results, scan results from other companies? And we do, but we mostly cannot share them. And I need to explain to people what we do about security all the time as well. So recently we've launched Amroko.com security, which is a half technical, half soft overview of what we actually do to make sure that your sites are all secure. So the one thing that we've added recently to that is that we're going to do regular audits. We've hired a security firm who will do focused pen testing on some parts of the back office that we think are important. So currently they're testing all of the authentication stuff that we have. So back office logins, OAuth integration, forgot password that we just added there. So all of the things that have anything to do with authentication, they're testing this now and we will get the results from them. Maybe we need to fix some stuff. And once we have done that, we can share the results there on Amroko.com security as well, so that you know what we do and what's been tested. And you can be more confident in our security. Whenever we do things in Amroko that might relate to security, we consult the OWASP rules for our recommendations for whatever might be sensitive. We have a few base classes in Amroko, so things like Ambroko authenticated, Ambroko API controller. No, the other one. Ambroko authenticated API controller. Sorry? Authorized API controller. That's the one. So API controllers, we use that to send JSON to the back office. And if they are authorized, then at least we know that people are actually logged in and we do some security stuff on there. So we have a few secure base classes that we can use throughout the back office and building Ambroko to make sure that everything new that we build doesn't compromise security and isn't publicly available. Of course, we're not perfect. We've had a few batch releases out there that we had to make because somebody discovered something horrible that we really needed to fix up. So hopefully that's no longer going to happen. A lot of those things were really old code. The first big one we released was applicable to 401 and upwards, which was very interesting. I managed to find all the old Mercurial repos and managed to actually build every version of Ambroko. It still works. You can still build Ambroko 4.1.7 if you want to. And we release patch releases for each one of those, so it's really easy to just upgrade or drop in a new DLL and then you're safe. So we try to do that as much as possible. If we can still build the old code, we will totally try and update it and send out a security alert to everybody. We rely on other people's libraries, so we try to update dependencies as much as possible. So that we actually have their latest secure versions as well. We're currently in the process of updating to new ImageProcessor, which has some mitigations against... I'm going to do the total techno speak. Mitigations against enumeration attacks. So whenever you add some more stuff to your query string, it will just regenerate a new image and a new image and a new image. So if you do that enough, and there's not much required, trust me, then not only will your server fill up, it will also start spinning up more and more CPU cycles. So we're updating that to be more secure now. And other than that, we do internal training. So whenever we learn something new, we share it with the team. Make sure to keep an eye out for this one. We also recently built a health check into Ambroko, which has a few security checks in there. Which also helps our team knowing, oh yeah, that's something that people do and need to be aware of. Yep, all of these details and more are on Ambroko.com security. Right. Contributions. Who's ever sent a pull request to Ambroko or have posted code? Ah, you're all awesome. If the rest of you want to be awesome, here's what you do. Hang on. Because I have an animated GIF and I'm not sure how it works on this thing. No, I think I have another sheet first. Okay, cool. So how do you contribute to Ambroko? So you're also awesome if you haven't sent a pull request but have done one of the other things here. Send us bug reports. Please complain. It's really annoying to me and the team, but it really drives the point home that something is broken. Okay. Of course, not everything we can fix and not everything is totally broken, but if it's totally broken, we will definitely fix it. If it's not totally broken, then we hope that you will also be helpful and try and fix it yourself and let us know how you fixed it so we can put it in Ambroko. That was my main reason to start contributing to Ambroko a few years ago when Ambroko was totally broken, as Stefan would say. It's like every little thing that annoyed me, I was like, okay, I need to figure out how to do this pull request thing so I can actually help these people and by that help my customers who are complaining to me. So I wanted the complaints to go away. So that's it. Complain, different development. It's amazing. So please send us bug reports. If you know how to fix it, let us know as well. If you have steps to reproduce the thing that's broken for you, then let us know as well. The more detail we have, the easier it is for us to figure out what the problem is and the easier it is for us to actually say, oh yeah, sure, we can fix that. If you say, eh, doesn't work, it's broken, I clicked something, then there's not much I can do. Then say, can you please provide some more details so we can look at it. So if you make a bug report, please be detailed so we can look at it immediately and quickly. Not everything is a bug. Some things are user experience issues. Some things are like, I don't know what to do. How to do this. There's a lot of bug reports that are just like that. I don't know how to do this. It doesn't work for me. Usually I have to send them to the forums, and then they can ask the community, who is usually very happy in helping out with that. And if you are happy in helping out with that, the forums are an excellent way to improve your own Umbraco skills. Again, personal experience was that I learned Umbraco by helping people in the forum. It's like, oh yeah, that person is doing something like that. That's really weird, but it kind of makes sense in that situation. Let's see how we can actually make that work. I got involved a lot when we first, and this was before I worked here by the way, when we first introduced Razor in Umbraco and nobody knew how this Razor thing worked. Is Christian here? Christian Steinmeier? You here? So Christian was the XSLT king, and he would always explain everything to everybody. I think you've probably learned some more stuff from the forum as well. I learned Razor by just doing it and trying to help other people do it. And eventually I had a package called Razor examples or something, which showed you with every data type in Umbraco how to make Razor for it and make it work. Maybe you should look that up, Christian, if you have some trouble with Razor. So super valuable, not just for people asking for help, but for yourself as well. Other things you can do, if you don't really want to help with that, you can translate stuff in Umbraco. So our translation files are on GitHub and you can just edit them online. Really easy, just click the edit button, click save, and then we will get a pull request immediately. If you are so inclined, you could make a package for Umbraco. Some edit functionality doesn't exist quite yet. It's pretty easy to start making packages. You can get packages out of stuff that you build time and time again. And if you do it just for your own company, that's great. But if you want to share those things, that's even greater. Oops, I should not stand on this thing. Yeah, who's built packages before? Yeah, fair amount. And have you shared them on our Umbraco? Very good, very good. Keep doing that. And then, of course, you can also send us feature requests. No guarantee that we'll implement them, but we will definitely listen. And if you do send us a feature request, then star. Maybe you want to send a pull request to go with that. And you don't have to just implement the whole thing yet. Maybe you could just say, I have this thing that I think Umbraco should have. Do you agree with that? If we say, sure. Do you want to build it? Then you can start doing it, and we will help you, give you guidance on where to start, in what files to look for similar things, what the... Yeah. In quotes, architecture should be like for a feature. And sometimes we'll just set up a base layer for you. So that's how the new health check got started. Shannon set up a few base classes that people could take and work out and make actual code for them, which we're totally happy to do if you have a really great feature idea. Yep. And if you're really not a coder, but maybe you're a front-ender, you can do some CSS fixes. There's Bjarne here. Bjarne is not here. Bjarne is my favorite person. He fixes, like literally, we call him the one pixel man. He goes in, shows us a screenshot of something that's one pixel off, and he's like immediately sending us a fix to make that better. He's amazing. Every little fix helps and makes everything look much nicer in Umbraco. So, high five to Bjarne. JavaScript, HTML, if you see textual errors, we are non-native speakers. So I'm Dutch, live in Denmark. Most people that develop Umbraco live in Denmark and are Danish, and their Denglish shines through all the time. So please help. Help. The documentation that's on our Umbraco is also editable. There's usually an edit button at the top there. So if you find something really wrong in the documentation, click the edit button. And you can online change it, save it, and then it will send a pull request to us, which we can then have a look at. A lot of people do that as well, which is really nice. Right, so how do you do this? How would you start contributing to Umbraco? Say you found a bug in Umbraco that you wanted to fix somewhere in the code. First things first, I hope this is going to work. You will need to forward this. Fork Umbraco on GitHub. So click the fork button. It will start doing things. You clone it to your local machine. If it's a non-trivial thing, sometimes you can just edit on GitHub. But most of the time, you just want to clone the forked repo that you have. Build it. Go into the build folder. We'll show that in a minute. Hit build.bat. That one downloads everything for you that you need. It sets up all the environments. All the environment variables that we need. It will build all the JavaScript stuff as well, which I don't know how that works. So I automated it because I didn't want to know how it works. I don't want to install grunt, npm, bower, dev, whatever these things are called. Just make it a batch file. Then I'm happy. Once you're done fixing whatever you do, commit it and then ship it. So push it back to your fork. And GitHub will automatically tell you, hey, you've got this. You've got new changes. Do you want to submit that back to Umbraco? Create a pull request here. We'll show you that in a minute. Sounds complicated. It's not. So first things, the fork button. So if you go to Umbraco, GitHub Umbraco CMS, there's a fork button on the top right. Ooh, 99.93. Almost there. Let's make it 1,000 after today, okay? It will start forking things into... So this one forks it into my own. So I'm going to do a GitHub repo and then you can start working. Then GitHub will tell you... Ah, this is the end result. At least it won't have afraid of. Okay. There we go. Quick. I have to find the sheet again. It's an animated GIF and it stops after the first run. All right. Well, I clicked the add button. I set clone here and it cloned it down. That's what happened. That's all. You can do this with any Git client. I just used GitHub for Windows here because it's quite easy. We were trying this yesterday and GitHub for Windows didn't work on Blake's machine, so I'm not sure what happened there. I used Git extensions. Git extensions is awesome. Stop using SourceTree, please. The next step, let's see if I just reload this, then maybe it will just play. The next step is to hit that build up path file. Basically what happens, you can't see now, is... A black screen will pop up and it will start listing out things. It will take ten minutes the first time because it needs to download everything, compile everything. And that just sets up everything for you to be able to succeed in actually building Embraco. So once you see these output files, so Embraco CMS, beta.zip, in this case it's called beta, and the new Git packages, then the build has succeeded and then you can be confident that it will also work in Visual Studio later. If you don't do this first, sometimes some of the things get a little bit off and they don't... Mostly the JavaScript stuff doesn't build. So try this first. If this doesn't work, there will usually be errors and you can start fixing them. Yes? Is it possible to switch or something? Is it possible to have a... Yeah. Okay. So... So we're not using it. All right. So you're building Embraco... From source. From source. Can I ask why? Yes, we can. We needed to do some modifications. Oh, no. Don't do that. Send us a pull request. Okay. Fine. If you want to do that... No, there's no switch. You can just take the build of that and take out the zipping up of the files and the creating of the new Git packages. And that's the same thing. Yeah. So yeah, just change the build of that. But if you have good changes that you want in Embraco, then please help us. Send us a pull request. Yes. Yes. We'll show you in a minute how that works. So Blake will demo that for you. Blake is famous. He's in the Foon newspaper today. Does anybody... Does everybody read Danish? She was interviewed yesterday and it basically says, this is my next project. My second conference, the Embraco conference. I work with Embraco every day. I paid for my own way here. But it's totally worth all the money and I'm looking forward to the weird bingo that's coming up. So Blake is going to do her first pull request right now. Let's see if that works. Okay. So we've already done these steps on her machine. We've cloned, forked, cloned, downloaded the source. We've opened... We started the build and now we've opened it in Visual Studio here. This bug in particular is... Do you remember what the bug was? When you were putting in the password to the database, if you had a semicolon in it, it wasn't escaping it. So it would break. Right? Very good. Okay. So, yeah, if you enter a semicolon in a connection string, it just says, oh, that must be the next argument. So I'm going to try and take the rest of it as a new argument and then Embraco doesn't work. It's a really silly bug. You need to escape it. All right. So it's issue number whatever. Yeah. Yeah. New branch. So she's got her own fork. She's creating a new branch of the Dev v7 source right now, and it's going to put the code in there. Okay. New branch. New branch. We've prepared the code, she doesn't have to figure it out on her own right now. So the simple fix for this is just to do a string format, do quotes around the password. I haven't missed anything, did I? You're going well. I will shout if you don't do it correctly. To be fair to Blake, she's not a coder. She's mostly front end and setting up in Braco document types and things like that. So this is all very new to her and she's doing an amazing job. So yep, you've committed it. You're going to push it back to your own Git repository. Sure, I want to track that branch. Cool. Yay. Okay. Right. Maybe refresh this page. Damn it, we tried this. I know. It worked earlier. This branch is even with Braco DeFi 7. Oh. Sorry. Yeah, maybe go in the branch drop down over there and find the, see if you can find the U4, whatever it was. I think you can just, I don't know what the number was. Maybe it's it. There you go. 7879. There you go. That's it. Now we get the thing. Okay. Great. Great. Yeah. So it's just going to compare it to whatever we have in Braco right now. So I'm going to go in and Braco right now and send a pull request for that. So I should see the pull request popping up over here right now, which you can't see, but it looks promising. That's amazing. I get an email and a Slack notification saying, oh, there's stuff. I'm going to type something. This is riveting. You can't see. You don't know what I'm typing. It's very silent. It's very silent. There we go. I said, hey, maybe you want to escape ampersands as well. It's XML. So it's going to break anyway. Okay. Ask Christian. He knows. So this is the process. If we get a pull request and it's not entirely correct, then it's totally no problem. We'll just give you your comments and you can change your, your, your, your, your code accordingly. There we go. So we're changing ampersands and lower than and greater than and quotes. Sure work. Looks good. Okay. Perfect. Sweet. Let's have a look at GitHub again. It now is updated with an extra commit. So it will just be in line with the previous commit. The pull request is still open. There's something running there. Some checks haven't completed yet. So we have a build server running for each commit. Okay. So we'll check all of your code if it's correct. And if that builds completely without, without error, I can be very confident that it will work. Of course, the functionality may be wrong, but at least the build will, will succeed. All right. So it says something here about it's out of date so I can refresh my page. I've looked at your code. It looks really good. Unsurprisingly, we didn't prepare this at all, did we? Looks great. And I can, I can merge this pull request into the core right now. There we go. Yay. You are now officially part of the core of Mbrocco forever. High five. Sweet. And so can you be. So I could now the issue tracker. So whenever we accept a pull request, I have to now actually go into the issue tracker. There we go. Where was it? So installer fails with DB connection error, blah, blah, blah. If I reload this now, so we ask for the issue number because we can then close it and set it to the next release. So we can say, this is hard, I can look here. The username? What's the, what username, sorry? Are you here, Blake? Is that yours? Ah, yeah, well, we don't care about that right now. We'll fix it later. This is a demo. I can set it to, but it's a good point. So I should actually have tested this and done it later. I can set it to 750. Yes, send me a pull request. So this one was up for grabs before, which is amazing. And it's now been fixed by a community member. So now it will start appearing in the list on our Embraco as issues fixed in this release. And I always like putting the contributor name in there so we can, like, look back in history later and see, oh, yeah, Blake fixed that. That was amazing. So yep. And, yeah, that's it. And this one, just for completion's sake, this one was unscheduled. We didn't schedule it for this sprint. Oh, what happened? Oh, I have two tabs here. Okay. Let's close this one. There we go. Present. Cool. So then, so the final bit, of course, after doing all this for a few weeks is that we build and release Embraco. We use AppFare as our, as I said already, you saw the thing running. It will build every commit that anybody makes to the Embraco core, even pull requests. So if they make it to their own branch, their own fork, I mean, it will build those as well. So we know we can be confident that they didn't break any unit tests. Stefan, sorry. You like breaking unit tests. And then I complained to him a lot. Yeah. Okay. Okay. So, yep. So every pull request gets built. If it works, then we can be confident that it's a good one. And then finally, after, so that's a continuous build. And then finally, after all of that succeeds, we can start testing internally. We install the NuGet packages and we install the normal packages and see if they work. We look through whatever new features we've built in or whatever things we've touched and clicked through and see to make sure that we didn't break anything worse than it was before. No, it was great before. And then we can merge everything into master. So we're working on DevV7 and eventually we merge into master V7. Again, that one builds. It's also on AppFare. It's a different build. That one is just a manual trigger. Everything builds. We download the final files that are going to, hopefully, going to be released as the final version that we're going to put on NuGet. Okay. Again, do some tests. Mostly it's installing NuGet packages. I always update our Mbrocco to the latest version on my local machine first to make sure that we didn't forget anything. So I didn't do that this time for the beta, so I forgot two config files. They need to be transformed. So if your health check doesn't show up or your new packages section doesn't show up, that's my fault. Sorry. So I need to fix that for the final release. Luckily, we found it now in the beta and it's not so bad. Yep. And then finally we deploy the release files straight from AppFare. So this is what the queue looks like for the normal development environment, DevV7. So it builds every commit. Jeremy sent us a pull request here. It's red. So something must have broken. Could be that we rebroke something right before that, though, because updated unit tests, to be more precise, looks... very suspicious. And Jeremy might have built on top of that. So we'll see. We'll see. Then once the release build is finished, we can go into AppVeya's deployment section. If you want to know more about AppVeya, by the way, it's an amazing tool, come ask me later or ask in the Q&A later. The deployment section has whatever was just built. And if I click on one of the... the last commit there, I have a big deploy button there and I can choose to deploy it to either NuGet or our Ambraco so that the final files will end up there. Oh, that was it. Did I forget anything? I'm not sure. Questions? Oh, I was very clear. Come on, what have you always wanted to ask someone from the core? There. How do you know which branch is broken? How do you know which branch is broken? Where do you change the fork from? That depends. So mostly you just fork from DevV7. We should... I should also say that... and we need to update this page, but we have a page on our Ambraco, our Ambraco slash contribute, which details all of these things. Our Ambraco slash contribute. So we have lots of documentation about all of these things, guidelines. We like people to use ReSharper. At least don't leave usings, unused usings there and make sure that all of the indentation of the files is correct. We're not Nazis about it though. We will just tell you, oh, indentation is a bit wrong, but I'll fix it. It's okay. So that one also says if you want to work on something that's for the next release, use DevV7. If you want to work on something for DevV8, then you should talk to Stefan and say, I want to change NuCache to XSLT. Because, yeah, it's important. So that would be DevV8. It might also be a feature branch. So the health check was built on a feature branch called health check DevV7 health check, I think. So if you want to contribute to this one feature that we're building, then it's that one. So either figure it out or just ask. Two. Yes. I don't know. Why don't you help with that? Why don't you help with that? What version is this? Okay. Try and upgrade to 7.4.3 and then tell me if it's still there. Not trying to be mean, but we fix a lot of things and I can't remember everything. I think we've touched that. I think that's the dashboard that's doing that. One of the dashboards, anyway. And I think 7.4 might have actually fixed that. So it might already be fixed. There was one there. It surprised me that you are only 7.0. Yeah. I know. We do a lot of things. A lot of our productivity also comes from your contributions. So this is why I have such a huge emphasis on please help because you're just making everything better for not just for yourself, but for everybody else as well. It's such a socialist way of working, isn't it? Oh, we are in Denmark. So no worries. How many people together are involved in the Bracco? I think we're 20 plus people now. I can't remember anymore. I don't keep up with the count. Go to Bracco.com slash team. That's where all our pictures are. We should update them though. Yep. We're a tiny company still. Doing great things. Big things. Not great. Well, you can be the judge of if it's great or not. Maybe it's also good to mention that you have great power. Oh, yes. Our website is also open source. If you are annoyed by something that's not working in that one, we would love your contributions for that one as well. Yep. It's also on our GitHub account. There's instructions on how to use it. How to build this thing is a little bit different than the new Bracco source. But basically, there's also a build up ad. You just need to do some extra things. But it's all documented. So if you need help with that, let me know. Good point. Cool. Anyone else? Yeah? Yeah? I found a bug in the starter kit. Which starter kit did you find a bug in? Just now I downloaded from the US. Yeah? The class unit cannot find it. Ah, okay. I don't know about that one. But should we also be able to announce that it's not working? Oh, yes. Yes. Please make an issue on the issue tracker. Yeah, absolutely. Yeah. Yeah. And then we can have a look. I don't know. Okay. Interesting. Oh. Okay. Okay. Don't call your web... What was it? Your solution, Umbraco? Ah, because it's going to be building Umbraco.dll, but your Umbraco.dll. Yeah, that will break, yes. Cool. All right. I think that's it. Thank you very much. Thanks, Blake. Thank you. There we go.