We did a number of things in the previous episode. We pushed our demo project up to GitHub. We built a new server and a new site. We then enabled Quick Deploy and added our SSH key. We then pointed a domain I purchased called Laravel Screencasts to our IP address. And then finally, we loaded it in all its glory on the page. So now, again, use your imagination. Imagine this is a real site. The next step is staging.laravelscreencasts.com. Okay, let's get started. I'll switch back to Forge and we'll create a new site here, staging.laravelscreencasts.com. All right, we'll scroll down. Give that just a second. Okay. And now it wants to know the Git repository. So once again, it's going to be this, but I'm going to do a different branch. It'll be our staging branch, but I don't yet have one set up. So let me do that real quick. Let's check out a branch called staging. All right, and push origin staging. Okay, so now we have two

It'll be our staging branch, but I don't yet have one set up. So let me do that real quick. Let's check out a branch called staging. All right, and push origin staging. Okay, so now we have two branches, one for master and one for staging. So the basic workflow would be you make some changes, you merge it into your staging branch. That then gets pushed to your staging server where you, your team, whoever, the client reviews it and ensures that everything's good to go. If all thumbs point up, you then merge those changes into master and you push it live to your users. So let's say the staging server here. Okay, so once again, I will enable quick deploy, but do note in this case, you're not pulling in the master branch, you're pulling in the staging branch. But now there are some things we should configure. So I'm going to go to my environment file here, and you'll see the database is still set to forge. Well, we don't want the staging

branch. But now there are some things we should configure. So I'm going to go to my .env file here, and you'll see the database is still set to forge. Well, we don't want the staging server to use my production database. Instead, we want the staging database. Later, we'll talk about some prefix considerations for caching and things like that. And then also here, this will be staging.laravelscreencast.com. Anyways, if we return to our app and we trigger a deploy, I think it's going to fail. And yeah, it failed. So the issue here, where is it? Yeah, unknown database staging. Of course, we need to create that now. So I'll just do it directly here, add a database called staging. And now, if we give it one more go, it should work. And you know what, I even think forge, I can't remember, but I think you can make a database on the fly now. Yeah, this is kind of a relatively new thing. So you could do it there as well. Anyways, if we switch

I even think forge, I can't remember, but I think you can make a database on the fly now. Yeah, this is kind of a relatively new thing. So you could do it there as well. Anyways, if we switch back, that should be done. So if I now come and refresh, we have a second database for our staging site. Okay, this is looking good. But if I try to run it, you'll see right here, Safari can't find the server. Because once again, there's nothing that says will point staging.laravelscreencast.com to the given IP address. So I'm going to do it back and hover. The IP address is the same. So I'll add an A record. Now I can either be explicit, or we can even do a wildcard here. Let's do this. That will point to our IP address. And again, set the TTL to five minutes. Okay, so after a decent pause, maybe 10-15 minutes, finally, the DNS has propagated. So I now have two servers, one for our main site, laravelscreencast.com, and then another