Hi, this is Taylor Outwell, and in this video, I'd like to talk a little bit more about what Envoyer does behind the scenes when we deploy our code. Now, you remember from the previous video that we deployed some code a couple times to our server. In this video, let's actually look at the directory structure on the server and what happened behind the scenes. All right, I'm already ssh into this server, so let's take a look. We're going to go ahead and navigate to this default directory, and as you can see, there are several directories here. One is current, which is actually a symlink into the releases directory. We, of course, have our releases directory, which contains our releases. Let's take a look at that, and we just have two releases from our previous two deploys, and then we also have a storage directory, which I'll talk about in just a second. Now, let's take a deeper look at this directory. As you can see, the current symlink actually

and then we also have a storage directory, which I'll talk about in just a second. Now, let's take a deeper look at this directory. As you can see, the current symlink actually points into the latest release within the releases directory, so when you push fresh code up to your server, Envoyer will actually download the code into a new release directory, which is a timestamp for the time that you're deploying, and then it will install your dependencies within that release directory and run any other deployment hooks, such as running your migrations and so forth, and then finally, it will switch the symlink of the current directory from your previous deployment to the latest deployment, and that gives you a zero downtime deployment story. Now, let's jump into this current directory. All right, and this is just our Laravel application, but you'll notice that the

deployment story. Now, let's jump into this current directory. All right, and this is just our Laravel application, but you'll notice that the storage directory within this current directory is also a symlink. Let's see where that points. It actually points back out to the default storage directory, and what this allows you to do is keep your storage directory consistent across each deployment, because you may be storing files in there or even sessions or caches within that directory, and you don't want to wipe it out on each deploy. Now, remember when we first set up our project. Let's go back to Envoyer. If I go to my settings, I can specify if this is a Laravel 5, a Laravel 4, or an other type of php project. That's how Envoyer knows how to manage this storage directory. When it sees that I'm trying to deploy a Laravel 5 project, it will automatically create a storage directory in my

project. That's how Envoyer knows how to manage this storage directory. When it sees that I'm trying to deploy a Laravel 5 project, it will automatically create a storage directory in my project path that exactly matches the Laravel 5 storage directory structure with an app folder, a framework folder, and then a logs folder. Then when I deploy my code, it will remove the storage directory from the fresh tarball clone of the repository, and it will link the storage directory to the consistent directory that's out here in the main project path. That allows you to basically deploy your code without even having to worry about any of those details and letting Envoyer take care of that storage directory for you. Like I said, that works with both Laravel 5 and Laravel 4, and if you have some other type of PHP project, you can use deployment hooks to manage this yourself, which we'll talk about in another screencast. All right, so that should give you