Barry van Veen has a quick post on his site showing the Composer users out there how they can use a package from a local directory without having to go through the hassle of pushing it and adding it to Packagist.

Suppose you run a website and want to split part of it into a package with its own repository. You start a new repository and check it out on your development machine. But now you want to see how the website and your new package integrate. How to go about this?

This article explains how you can require a package from a local path into your project with Composer. This way you can run a local copy of a repository and test any changes you make. Because the local repo will be symlinked changes are shared in real-time, there is no need for intermediate committing and updating.

He shows how to update your composer.json configuration's repositories section to add an entry with a "type" value of "path". This then points to the location on the filesystem where the package resides. Then it's just a matter of requiring the dev-develop branch and the code will be treated just like any other package. He also includes a section showing how to handle things when symlinking fails, a problem that usually happens on Windows for VM users. Usually it's related to a permissions error for whatever user is running the VM.

Matt Stauffer has a post to his site today sharing a step-by-step guide to setting up your Laravel application for zero downtime deploys when using the Envoyer/Capistrano combination.

The reason you're getting zero-downtime deploy from these tools is because the entire deploy process—clone, composer install, etc.—doesn't happen in the directory that is currently serving your site. Instead, each new release gets its own separate "release" directory, all while your site is still being served from its current "release" directory.

All of these release directories are just subdirectories of releases. Each directory here represents one of your deploys, and each directory individually has everything needed to serve your site. [...] So, once the build process is complete for each new release, your deploy tool will delete the current symlink and create a new current symlink that points to your latest release. Boom. Now that release is live.

He then relates this back to the deployment of a Laravel application with Envoyer which already follows this "symlink deploy" method. There's a few caveats he mentions with this deploy, however, including information that shouldn't be removed in each deploy (like caches or configuration files). He then provides the steps (commands) you can follow with the deploy to manually use the "symlink deploy" method in your own scripting.

In this post to his site Freek Van der Herten shares an Envoy script that can be used to deploy an application to a remote server with (or without I suppose) one key thing: downtime.

Envoy is Laravel’s official task runner. Using a Blade style syntax tasks can be defined that can be run both locally and remotely. At Spatie, we’ve been using Envoy for quite some time to deploy code on production servers. [...] [Our trusty Envoy scriot] had a big downside: the application would be down for close to a minute. This week I took the time to solve that issue.

He talks about the changes he made to their deployment process towards using a symlink-based system as suggested by this guide. The result is an updated script that follows the same flow. He steps through the changes he made to the script and tweaks used to get the best performance out of the deploy process.

Lorna Mitchell has a handy tip you can use in deploying your (linux-based) PHP applications - a one-step symlink switch that can make toggling between deployed versions of your code simple.

When I deploy an application, which is almost invariably a PHP application, I like to put a whole new version of the code alongside the existing one that is in use, and when everything is in place, simply switch between the two. As an added bonus, if the sky falls in when the new version goes live, the previous version is uploaded and ready to be put back into service.

The single command avoids having to remove a current symlink and recreate it, possibly causing issues if something happens in between. Instead she uses the "mv" (move) command to push the current symlink over to a new location. Reducing the process to one step also minimizes the risks of deployment.