Umbraco as a Service and Visual Studio

Alright, well I guess we can slowly start, even though we're starting early. Welcome, hello, my name is Morten. Yes, it works, perfect. Then we don't need to edit the video, it's perfect. Welcome, glad to see many of you here. So today we're going to talk about Umbraco as a Service and Visual Studio. Talk about how you can work with it now and kind of what our visions are for the future. Because we're in an exploration phase right now, so we'll talk a bit about that. But first, my name is Morten. I didn't really know what to do with the introduction, so I looked to LinkedIn for some help. So these are my top five LinkedIn skills. Apparently. Apparently I'm very good at CMS. It's good, I guess. Maybe they should have been changed a bit, but I don't know. Anyway, the agenda for today is, apart from cool transitions, we'll talk about what's actually in an Umbraco as a Service repository. When you create a project, what do you get out of the box? We'll talk a bit about workflow, and I hope that it won't be boring. I think it's important to iterate over this. Then we'll look at the Visual Studio setup that we currently have. A bit more about workflow. And then about ideas for the future and how you can work with Visual Studio a bit more seamless in the future, hopefully. But we'll get into details about that. And there are some demos included, of course, throughout. And if there's enough time at the end, I have some extra demos. Hopefully get some feedback on that. We'll see if there's time for it. But how many of you have already created an Umbraco as a Service project today? Tried it out? A few? Okay. Well, you should try it out. Now we have a really cheap price. Anyway, so we've changed it a bit since yesterday. You saw that Niels introduced flexible plans. So when you create a project now, you can start with a single environment plan and kind of go from there. So just kind of go through in the portal. When you create, you probably start with a single environment. Create a project. This is how you do it in the portal. With single environment, we start from the 25 euro price. You can add additional environments. So here we can go ahead and add a development environment as well. So just spend time and space and make it a bit faster. But if you need a staging environment, you can go ahead and add that as well. Some people prefer that their editors work in a staging environment, create the content there. It's totally cool with us. You can add an environment, additional 20 euros, and kind of go from there. So it's all on the fly. And you can remove it again. So here we don't really need the staging environment for this demo. So we'll just remove it again. And then we're back to the 45 euros. Oh, I should have switched off notifications, I think. But yeah, so when you create this, what's actually in an Umbraco as a Service environment or a project? So in this, we created a project with two environments. Each environment you can actually clone. But what does it contain? Of course, it contains Umbraco. It contains Umbraco forms. And it contains Umbraco deploy or Courier. So there's still Courier, but we've kind of switched to calling it Umbraco deploy because it's more in line with what we want Courier to be or Umbraco deploy to be in the future. But this is part of it. And this is actually the only thing that's kind of unique to Umbraco as a Service. All the other stuff that's just standard is the regular Umbraco release. No different than you can download from NuKit or the zip file on our Umbraco. Forms, also the same. Umbraco deploy, it has a different UI than the regular Courier that you might know. It has a specific config file which tells Courier about the different environments that you have in your project. So like when you clone it, it's like, if you clone it locally, it'll know about the development environment and the live environment and other environments that you might add or remove. And then, of course, all of this is in a Git repository. So each environment, the development environment, the live environment, when you create a staging environment, all of these environments has their own Git repository. Which means, of course, that you can clone it and start working with it locally. So let's have a look at that. So basically from the portal, you have this connect my machine up here, which helps you get started. When you're on a single environment plan, you would be cloning the live site. If you have multiple environments, you would typically be cloning the development environment and work with that locally. So basically just grab your Git URL, clone it locally, and then, yeah, in space and time again, so it's a bit faster. And these are the same credentials that you use to log into the portal and Bragg as a service that you use for everything. Both the Git repository, the back office login, basically everything. Yeah, so let's try and speed that up a bit. See if it works the magic. Oh, that was fast. And so when you have it cloned locally, you can start it in either IIS or IIS Express, depending on how you want to do it. We prefer to work with it here. We started in IIS Express. And this site is actually configured for you, so when you clone it locally, you just need to start the site. You don't need to worry about anything else. As you can see here, it created a SQL CE database. Oh, I was not fast enough. But it created a SQL CE database on the local site, which it starts using. And basically you just log in with your credentials. As you would in the portal. This is locally, but it still works. So just log in. Here we check. There's nothing in there since this is a blank repository. But this is the latest version. So that's, I mean, just having a repository, it's pretty easy to get up and running with a website. But I'm guessing you're here because that's not how you usually work with a website. But this is kind of how we've done in the past. When we didn't have the Visual Studio approach as part of this. But let's talk a bit about workflow. So what we talk about in an Umbraco as a Service project is metadata, which is the structure of your website. So that's your document types, your media types, member types, member groups, macros, templates. All of the stuff that's part of the structure of your Umbraco site. That's what we refer to as metadata. And when you work with that, you usually create your stuff locally. Or you can also do it in development. So you might iterate over document types on the development environment on Umbraco as a Service. But you can, of course, also do it locally. And then you push it forward. So you push it from left to right, basically. From your local machine forward to the remote. And then onwards towards live. And code is pretty much the same thing. I mean, you usually create code locally, right? So commit that to the Git repository. Push it to the remote development environment. And then forward again, also left to right. To development, staging, live. For content and media, slightly different. Since this is typically content editors. That works with content and media. So the typical approach would be to create content and media on live. There's, of course, some that prefers to do it on staging. And then they can actually transfer that content from the staging environment to the live environment. Just using the back office. So it's kind of the same feeling as you would normally publish content. Here you just select queue for transfer. And then they can transfer it to the live environment. And then, of course, you also have the option of actually, as a developer, pulling all of this content down. So that's basically going the other way around. So if your content editors works in live, you can, from your local machine or from the previous environment, you can actually restore that. So basically be pulling it down the other way around. So from live to staging, from staging to development, and to local. You can also, from your local machine, just say, well, I want to restore directly from live. And that will give you everything from the live environment. So just a quick recap. So just to make sure that you kind of got all of that. Metadata plus code flows from left to right in your local machine all the way up to live. Oops, sorry. Wrong way. Content media flows right to left. It's born in either the live environment or the staging environment. You can pull it down the other way around. So, yeah. So Visual Studio. So we have a Git repository with Umbraco in it. How can we actually make that work with Visual Studio since that's the entire Umbraco site in a repository? So the current approach we have to it is to actually have a Visual Studio solution with a website project. I didn't hear anyone scream, so that's a good sign, I guess. Matt loves it. So I kind of told my son that we made this approach of having a website project. And this was more or less his response. It could also have been the music in the background. I'm not really sure. But maybe he didn't understand it. But it's actually a good fit for this setup. Because when you have a website project, it basically shows you everything that you have on disk. You don't have to include stuff in your Visual Studio solution or project. So it's basically, yeah, more or less plug and play. Well, we made it plug and play. We actually worked on this small command line tool that you can just double click from your local machine. And then it configures everything for you. So you don't have to worry about setting up this solution in Visual Studio and configuring the projects correctly. So what we have here, the command line, basically run that. Give it a git clone URL for the development site. Use, again, the same credentials. You give your Visual Studio solution a name. So there will be the name space. Here I just called it VS DevSite. And then it will create two projects. First it will clone the site locally. Set that up. Then it will create a Visual Studio project with the right name. And it will install all of the NuGet packages locally so that you actually have those references in Visual Studio. Okay. So you get both the web project. You see here. In a minute. Let that finish up. So you see that's done now. So what we have here is we have the web project here. That's what contains the Umbraco as a service git repository. The core folder. That's just a regular class library. So there's nothing special about that. And then it has all of the NuGet packages as well. And both of these projects references the correct NuGet packages which corresponds to the version of Umbraco which you cloned into your local site. Okay. And when you open it up in Visual Studio, this is what it will look like. Yeah. You can see the website here. And basically with this you can hit F5 and start working with it. Oops. Here we go. Working with the solution. So just to illustrate here, we open up in Visual Studio. Hit F5. And then go into the back office. And from there we can start installing a starter kit. So here the starter kit I'm installing here is just a very simple one which we used for the workshop last year. So just to have a quick side up and running. So we can look at the files that you didn't get on disk and what you actually need to commit in the Git repository. All done. Check the website. It should be a giant picture of Sebastian. Yes. There we go. That's Sebastian. Then from the file system. Here's the files that we commit. That's everything that was added by the starter kit. Here we have within this data revision folder, that's all of the metadata that Courier or Umbraco deploy has serialized to disk. So that's some of the stuff that we need to ensure that's committed. When we then push it to the remote environment, Courier will make sure to extract it. So all of the metadata that was installed by this package will show up. In the development site. So here just jump to the portal. Open up the project. And you can see here this is the files that was committed locally. That was pushed. And then we can from there just click in the portal to go directly to the back office of the site. Log in and then we won't have any content yet since we've only pushed metadata. But we can see here that's all of the content that's there. And then, I'm not sure if you noticed before, but aside from the Umbraco as a service Git repository, we also have another Git repository, really. Which is the root of the website. Here. So. Like the surrounding. Just a level above the Umbraco as a service Git repository. We, as part of this tool, we create another Git repository. Which is where you'll commit the code from your project. So here we're committing the solution and the project file. When you start creating controllers and all of this, you can have that in your project above there. In the core project. And then you can basically commit that. So you can set your own remote to your own GitHub repository. Push it there. So that it's kind of separated from the Umbraco as a service repository. That also means that you have to actually commit the build output from your solution. So when you build and it creates the core assembly, you have to commit that to the Umbraco as a service repository. And push that to the remote. To the development environment. So the workflow in this is pretty much the same as before. Yeah, question? What was the setup of the script? Was it made in the Umbraco as a software module? No, not as a software module. No. We... It could do that, yeah. We've iterated over that. And we actually have a... We actually have that fully documented. But we kind of decided that it was too complicated. To actually get up and running with that. But we have the documentation for it. So if that's a route you want to take. It's definitely possible. But the general feedback we got was that it was too complicated to set up. So that's why we have it separated. And we have ignore rules set up. So that it doesn't interfere with each other. So it is totally separate. Even though it's nested. Yeah, John? There are two GIFs in that piece. But do you both get them from the Umbraco as a service? Or do you need to set up your own one for the core? So the question is if both GIF repositories are from Umbraco as a service. No, they aren't. So the outer GIF repository. That's just a raw GIF repository that we create as part of this. So you have to set your own remote. And use your own GIF repository for that. But aside from that, the workflow is basically the same. Again, metadata code from left to right. And content you can get all the way around. So as I mentioned, we have with this approach. There is a few challenges. There's a few things that you have to be aware of. When you work with this approach. So we've already kind of discussed the two GIF repositories. That you need to commit the code to one repository. And the Umbraco runtime more or less. To the other one. Push that. And when you... When you work in a team. Then each developer who works with this. Actually have to clone the Umbraco as a service repository. As part of this. Because when they fetch your own repository with all the code. Then it won't know about Umbraco as a service. We do have a command line tool for just double clicking. And then it will clone the same repository. But that is kind of a hurdle right now. It works. But it's just something to be aware of. And as I mentioned. You have to commit the build output. So when you work with it locally. Create code. Build. Make sure to commit that assembly. To the Umbraco as a service repository. And push it. But so yeah. We've iterated over this. And... We think we can do better than this. It works really well right now. But what if we could actually just do... File new project. And then from within Visual Studio. Just install Umbraco. The NuGet package. Install Umbraco forms. Those two are already on NuGet. So that's possible now. And also install Umbraco deploy. And from there. Just configure the build. And... Yeah. As in build. As in MS build. Of course. And then either use our service for building. Or bring in your own service. Build server. So we've gotten a lot of feedback during these road shows. Where a lot of agencies already have their own. Sorry. Been talking too much these past days. Where they have their own Team City for example. Or they use Visual Studio. Studio Team Services. And they don't want to get rid of that. Because they've invested a lot of time. In actually configuring this. And setting it up. So we'd very much like to have an approach. Where you can either come with nothing. Use our service. Or if you already have a setup. Use your own setup. And then the end goal is of course. That it deploys to Umbraco as a service. So let's have a look at that. Okay. So... So you can see that. No, that's still demo. There we go. To find the right screen. Yeah. So here I have a project. That I set up specifically for this. So this demo is using Visual Studio Team Services. And then I have my code here. On GitHub. And let's take a look at the solution. See the right one. This one. Over here. Yeah. Basically just a regular Visual Studio solution. This is just a web application. I added a class library to it. It has the same... It has the same starter kit installed. Let's just hit a five. So we can see the web application. And let's open it up here as well. Oh. Okay. Okay. Yeah. Alright. This isabel's... I mean... I should do this quid pro quid approach. Yeah. Well, there's... This... I mean... Come on Visual Studio. There we go. That's the website. So let's just go back here. Just change one thing so we can actually deploy something. See if we can change these around. Yep. Okay. Let's just stop this for a minute. And then you need to be able to see this. And see this. You see that? Yeah. Okay. So. So this is the file that we changed. Yeah. Command line is much better. Okay. There we go. So. Let's just check that it was pushed to GitHub. I think there was a commit there. Yes. So now if we go to Visual Studio Team Services. There should be a build here. Cued. Cued. And so this took a bit of time to actually complete. And unfortunately. I can't. I can't spend time in real time. Spend time and space in real time. But so what we go through here is a very basic build setup where we basically just build the solution. We also have some tests. I don't have any tests in this project. But we can run tests against it as well. Then when it's done running this build, it'll go ahead and deploy it to Mbrako as a service. Okay. So. So. So let's. While this is running. Question. Yeah. Is that the. Or is it. Is that an extension? If. If. Sorry. Is the. Task. Deploying. Is that an extension? Yeah. So. So the question is if the task of deploying is an extension. So Visual Studio Team Services. And yes it is. So let me just go ahead and show you this. And find my mouse. So while this is running, you can see down here now. I don't know how. If it's difficult to see. But it's. So down here. It's cloning the Mbrako as a service repository. So that's the development repository for this project. And then it'll go ahead and copy the build output from this build. And commit it to the repository. And then deploy it to Mbrako as a service. So let's just go into the edit mode here. Then you can see I have my build here set up to just know about the output. And where to do the deployment to. So you can see here I've configured my Mbrako as a service git URL. Give it my credentials. And aside from that it's pretty basic. The nice thing with Visual Studio Team Services is that you can build up your build and deploy pipeline like this. Just adding tasks. So this is not live yet. So if this is something that you want to try out. Then please let me know. I'd love for others to try it out. But right now this is just deployed to my account. So this is the one right here. So we should add it. Let's see if the build is actually done. Yeah. It looks done. And you can see here that it actually said that this was deployed less than a minute ago. Try and expand that. And you can see the assemblies of the build is committed. And the view is done. That we updated. And jump into the back office here. Did I miss type in? No. Okay. I don't think the internet guards are with me today. So let's go back to this. So that's kind of our thoughts of the future. That you can either use our service to build your project. Or use your own build service setup and build it. And then we'll provide extensions for something like Visual Studio Team Services or Team City. So that you can actually easily deploy the build output to Umbraco as a service. And when we talk about this setup. The workflow is slightly different. When you use this you should really be developing everything locally. So of course you'll work on your code locally. But when you iterate over your site. When you create document types, media types. All of these structural elements. You really need to be doing this locally as well. Because this is kind of a one way thing. We have some thoughts about going the other way. But ideally this is, I mean, you would have this, all of this stuff locally. And when you work with us as a team. You would pull down the Git repository. And get their updates. There's a question over here. So the question is. If you use your own packages like Archetype or Nested Content. And install that in your solution. If you need to commit that to your repository. And no, it'll just work with NuGet. So it'll be the same thing as working with any other Visual Studio solution. The build output will be committed to the repository. Yeah, the question in the middle. How can you see the other people? Yeah, that's a good question. I actually have a slide for it. What about updates? It's almost like I knew it was coming. But so, this is very early stage still. So we don't really have this part in place. But what we're thinking is that we would send you a pull request. So you would connect your Git repository to our service. Let's say if it's something like on GitHub or Bitbucket. If you connect your repository to our service. So that we know about it. When there are updates. We can actually send a pull request to you. Saying we updated your site. Here's a pull request. Please merge this in. That's the approach that we would like to take. So at least that's what we're exploring right now. Another question? Yeah. Yeah. Sorry, what? So the SQL CE database is only for when you work locally. But yeah, so that's what you get kind of out of the box. So when you start the site. It's kind of configured already. And it will automatically run a SQL CE database or create one for you. If there isn't one. You can change the connection string if you want to. So if you prefer to work with SQL Express on your local machine. Or something like that. You can do that. I would usually advise against having a shared database. Because that kind of defies the purpose of having an isolated environment. Because you can work with this locally. When you're ready to commit it. So if you added a new document type. A new template. You commit it. And then push it to your repository. Your colleagues can pull it down. And that will be automatically extracted. As soon as there's updates. Yeah, so I actually had this. I guess we should have had this earlier. Any more questions? Yeah. I have a slide on how we do configuration for each environment. I don't have a slide. But I do have. I have a configuration file. So we can take a look at that. Do you want to read it? Yes. Sorry. The question was if I have a slide on the configuration for environments. Yeah. So it's not in web config. But I'll show you. Let me just find one here. One sec. Okay. So this is a configuration file for two environments. And this is what Umbraco Deploy or Courier uses. We have the environments. Oops. Up here. You can see you have a development environment. A live environment. And then we have. Let me scroll a bit. And you have the URLs to these environments over here. So that's how we kind of know about it locally. So when you need to restore content to your local machine. This is. It knows that this is where it's going to fetch it from. Okay. Yeah. So if you have app settings or special configurations per environment. What we have right now is that you can have web config transforms or config transforms. You create. Right now you create one per config file. And then you name it. name it with the name of the environment. So if you have something that targets the live environment, for example, some Google Analytics key, something like that, then you can create a web config transform and put live in the name. We have documentation for this, actually, up on our, believe it or not. We do. But that's the approach we have right now. So, yeah, that's how we would do it. Was there a... Pete, did you have a... You had a question? What about media and things like that when it comes to setting that down, treating that down into... Yeah, so basically the question is, what about media when you push it to remote development or live or when you pull it down? So the media is local. It's as local to the website as it is right now. So that means that when you do a restore from live, let's say you start from scratch, you have a site that's already gone live, then it's going to download all of the media files to your local machine. It could, yes. What about... What about options like blob storage and CDN and stuff like that? Yeah, so the other question is, so what about options like blob storage and CDN? Yeah. That's something that we're exploring right now. So we don't... We know that it works, but we don't have it as part of our plans really right now. So it's still something that we're exploring and trying out and see how best we can fit it into the service also so that it still matches the price that we can offer. You could, yeah. You could, but yeah, I mean, it works, but it just has to be part of the service or did it... Yeah. It's configured for you. So it works now. And James South has made a provider for this world that works really well. So that's it. We know that it works. We just have to kind of know, fit it into the system. There was a question in the back. Darren? Where you can download the console app. Yeah. Yeah. That's on umbrago.co.blog. That's something. I can remember. I'll make sure to post a short URL so that you can all get it. Unfortunately, I didn't put it in my slides, but we'll put it up there. It's currently, it's linked on Sebastian's blog post. He wrote, my colleague Sebastian Jensen wrote a blog post about the setup with Visual Studio and a website project. So cultiv.nl has a link to this command line. Sorry, what's the name of the console? Sorry. It's, right now it's theoretical. Yeah. So it's definitely possible in VSTS. I still have as a pending task to actually set up TeamCity and make it work there as well. But it should be fairly straightforward. So. Yeah. Sounds good. There was some other questions over here. Yes. Yes. Yes. About the second demo. Can that be possible for the school board if you go in this world? How long? Yes, you mean the demo of using VSTS? Yes. Yes. You mean when you can start using this yourself? That's a good question. I don't know. But if you have, do you have Visual Studio Team Services? Jenkins, okay. Yeah, that's a bit tougher. If you said TeamCity, then I would, yeah. I don't know. I don't know about Jenkins, so that's a bit more difficult. But we can talk afterwards, and then we can exchange information, and we can look into what we can do there. But I think VSTS and TeamCity is probably the ones that will try and create extensions for Up first. That's the first thing. Yeah? You had a question? Yes, so am I correct to say that I must commit my compile to build output because Umbraco's service is not built? Yeah, yeah. Umbraco as a service itself does not run any builds, so that's basically the runtime that you're committing to the Git repository. So if I commit my own DLLs, the references would be correct on Umbraco as a service? Yes. So what about assembly binding redirects? You can... Yes. Yeah. So the question was if you change web config and update the assembly binding in web config, if that also works, And yes, it does. Was there any other questions? Yeah? Yeah. Yeah, so let me repeat to make sure I understand. So in the demo with the build that was deployed, through VSTS, what about metadata? Because I only changed the view file. Yeah, so basically it would work the same way. So you would go into the back office, create a document type, then you get a file on disk. Let's see, it might be a bit too slow on my machine right now, but basically you do the same thing. From the back office, create something, you get a file on disk, commit it to your Git repository. I can show you on GitHub. So my mainAMX очень Nicole Ale Duncan, you have a complaint with that file, or, something that it needs for example, media types, templates, all of the structural elements, serialized to disk. So basically you commit this to your Git repository, and then when the build is done running and it's deployed to Umbraco as a service, then Courier or Umbraco Deploy will take over and make sure to extract all of this. And so when you work with it locally, you have the same Umbraco Deploy config, and that's one of the reasons why we haven't made this available right now. We need to figure out how you can actually get this config file to your local machine when you start working, because when you start working, installing your Git packages, our service knows nothing about your repository. So you kind of have to make this link of, let's say you authenticate against the service and then say, this is the site I'm working with locally. We'll give you a config file, and then that'll be part of your local setup so that it knows about the different environments. Does that answer it? Okay, great. Any other questions? One in the back here. Sorry, I didn't get that. Yeah, so this is part of the portal right now. So you have a team set up. Let me jump back into the portal over here. So for this project, I go into the portal, into edit team. So there's only me right now. I can add an additional member. If I don't add him as admin, he'll be read-only by default. That means that he can't do anything except actually view the site itself. So the person that gets access to this project with read-only won't be able to deploy it through the portal. And that's on the code and metadata side of things. For users in the back office, it's a bit different because that's a context menu. So you might have some content editors that need access to it. So that's handled in the back office. Any other questions? No? Are we over time or before time? One more question, yeah? Yeah. How do you use it? Do you use it in other ways? Are there extensions in Visual Studio? Why I'm using Git extensions? Well, I actually prefer to work on the command line. So I just need something where I can right-click and then give me a nice overview of the Git commits. So when I commit to Git, I personally don't use Visual Studio. But that's just a personal preference. Any other questions? No? So, well, I guess we have 15 minutes left. I guess because I can show you another demo. I'll just switch my screen setup a bit here. Okay. So if you're interested in this, you see. So what am I actually demoing here? So this is a prototype of working with branches locally on your local machine. So this is just an empty Git repository. Well, not totally empty, but it has an empty Umbraco site that I've cloned to my local machine. See here. As you can see, there's nothing in here. No document types either. Let's go in here. Command line. So right now, so this is on a branch called development, which I created before this. But so if I want to do something slightly different, so just create a new branch called starter kit. Because I, yeah, if you want to try out a starter kit in this setup, see if it's something that matches my current project. Okay. See package. Unfortunately, this is still the old package installer. So it'll warn me quite a few times not to install anything. Okay. Let's install it. Yes, I'm definitely sure I want to install it. Okay. Come on. It's not that big a package. Here we go. Installed. Okay. So while it's installing, this is a regular Umbraco as a service site. Cloned it locally. I changed the branch. I do have a little bit of magic in there, but think about what you think, or what you think will happen when I switch back to the development branch. So right now, I'm on a branch called starter kit, and I installed a starter kit here. Here's my website. Umbraco. There we go. This is Sebastian again. There we go. Let's log out. Then back up the command line. Just. Add everything. There we go. So now it's committed. Let's go back to the development branch. So what do you think will be in the website now? No. So there was one personal guess that it would be empty. I see. Oh, shit. Refresh. Damn you browser cache. Reloads. There's nothing. Settings, document types. Nothing. So how does this magic work? Are you making Korea watch go back or do you have to do something to make it back? So, yeah, as you can see here, I've committed everything to Git. So I created, of course, when I clone it, I have the master branch. I create a new branch called development. Then I branch off of that as well again. So it's still empty. Then I install the starter kit. Of course, I get a starter kit. I can change back. Starter kit. Is that one? Switch to starter kit. Browser cache. I love you. There you go. It's back. And there's the trick. Because I have actually multiple databases. SQL databases on my local machine. One for each branch, which allows me to check out another branch, work on that, check out another branch, work on that. If I want to continue with that, merge it in, continue. So I can actually merge this in. So the only thing to be aware of with this is that if I merge starter kit into development, then I won't actually have any content. Because content is not available. Well, let's see. I'm on starter kit. Check out development. So let's merge this in. And then probably need to just kick career. Websites. So just take a minute to start up since there's a lot of stuff in there. So let's just reload this again. Reload. No. No. Well, there shouldn't actually have been any content. Let's see. Maybe it didn't refresh the site. Yeah. Yeah. The starter kit had content. So, yeah, I'm not sure what happened here, but what will usually happen is that so you merge all of the stuff that you committed to your software, starter kit branch, merge that into development. That means all of the structural data will get in there. The content remains in the database. We don't have that on disk. So that means that it would actually start up if it had worked correctly, that would have been a lot better, but it would have started only with the metadata. So the content section would have been empty and you would just have your document types in here. And so it remains in the starter kit database. So I must have done something wrong. Or it wasn't updated the connection string. Yeah? That button, open local branch of the . Sorry, which button? The one in your dashboard. Open local branch. This one? Yeah. Oh, so this goes to the portal. So this is a dashboard that was added yesterday as part of the new Umbraco sites. So when you create it, and work with it locally, then you have this overview of your next environments. Sorry? Yeah. Yes. Yeah, that's a bit misleading maybe, but yeah, I called it local branch. Any other questions? No, okay. That was it for me. Thanks for coming. Any other questions? Okay. That was it. Bye. Thanks. See you next time. Bye. Bye. Thanks. Bye. Bye. Bye. It's just there for success. Yes, there is also a branch. If you are branches located, then you branch in the real world. It's not really an engineer. No, it's local branches. But because you work locally, we can operate a SQL database for each branch you create. Okay, so you just edit the branches and create a new SQL branch? Yes, it's just a demo of how you could do it. It's not something that's in it now. It's a prototype. Okay, I see. But yes, it could work like that. I don't know, I don't think it's a refreshable branch. You can see that the database doesn't have the same size as the other ones. But that's because you go in and smell the poison in the wood, and you use it. Yes. Okay, thanks very much. Thank you. Thank you.