Configuring Deployment Server(s)
Now that we've looked at what Deployer is, its directory structure, and installed it, it's time to start configuring our setup, so that we can get ready to run a deployment on our code.
The Main Configuration File
Deployer looks for a file in the current working directory called
At its simplest, it's nothing more than a PHP file which contains the configuration Deployer will need to know where, and how to deploy.
Conceptually, you can break this down in to several parts.
Firstly, you setup the servers which can be deployed to, whether local, remote, or both.
Then you have runtime settings, such as the code repository, and number of releases to keep (for rollbacks).
Then you have the task configuration.
You don't need to add in custom tasks, as you can make use of a range of in-built ones. But if you need to, which may often be the case, you can add them.
Then you configure your core deployment task, which can be either a custom task itself, or the composition of one or more existing tasks. After that you specify any hooks which run either before or after a task, such as a notice to say that the deployment's done, or reloading Apache or Nginx.
Now, let's step through up until the server settings.
In the next lesson, we'll pick up with creating and configuring tasks.
Setting Up Your Server Configuration
Firstly, we need to include the composer autoload script, which is common place today.
Then I'll include an existing recipe. As I hinted at earlier, a recipe is, essentially, a set of existing tasks, based around a particular use-case.
In this case, the composer recipe is a simple set of tasks which could be expected to be needed in a simple, composer-based application. It includes running composer, creating directories, creating symlinks and so on. Perfect for my simple application.
The manual indicates that, in time, there will be recipes for a number of the major PHP frameworks, Zend Framework, Yii and Laravel. Fortunately, a basic Symfony recipe is already in place.
In my simple scenario, I'm creating one local server, which will be my local testing copy of the application, and one remote server, for production.
First I'll create the local server configuration, mainly as it's the simplest.
I'll do that by calling the
localServer(), giving it a name, that being
Then, using the available fluent interface, I'll specify the user to use, which is my local user account, the stage name, testing, and then set an environment variable, which is the deployment path, by specifying the key of 'deploy_path', and the key to the path to deploy the files to.
I don't need a special configuration in this case, so one environment variable's enough. But if you need other environment variables, then add more calls to
env(), as required.
Now let's setup the remote server.
As it's remote, it'll require some authentication to obtain access.
localServer(), this time, to work on a remote server (which can be a virtual machine), I'll call
server(), passing in the name, hostname or IP address, and the port.
After that, I'll specify the user and password credentials, the stage, and the deployment path, as before.
Nice and simple right?
Deploying to this host, Deployer would login to
192.168.10.10, using the credentials of vagrant/vagrant and deploy to
But what if you're working with a host such as Digital Ocean, which uses SSH keys? Then you're going to need a slightly different approach.
In that case, remove the call to password, replacing it with a call to
What this does is to make use of your ssh public and private keys during the authentication process. I'll assume that, if you need to take this approach, that you've already setup your public key on your remote host, after creating them locally.
Assuming that your ssh keys are stored in the default location of
.ssh, then you don't need to pass anything to the method. If they're not, or you want to be specific, you can pass to the method, firstly your public key path, then your private key path, then the pass phrase, if required.
To learn about public keys, and generating them, check out this post from GitHub.
SSH Config Files
Now using SSH keys is better than specifying credentials, as it's more secure.
But what about adding a bit of extra simplicity and avoiding code?
If that's what you're keen on, then you have two options.
You can either use an ssh config file, or a Server config file.
An ssh config file is a little outside the scope of this series, but in essence, is a way of specifying how to work with a server. Take the following example
Host dev HostName dev.example.com Port 22000 User fooey
This file specifies that when an attempt is made to connect to
dev.example.com, to connect on port
22000 and provide the username of
If that sounds like a good approach, or one which you're required to use, you can find out more about them in this great post from Joël Perras.
***To use them, remove the calls to the pass, and
identityFile() method, instead making a call to
configFile(), passing the path to your SSH config file.
Server Config Files
Now let's look at one more option, a server file. This allows us to specify all of the options outside of code, which can often time be a good thing.
Have a look at the following example:
prod: host: domain.com user: www identity_file: ~ stage: production deploy_path: /home/www/
Using the YAML file format, this provides all of the details we've seen so far; those being the environment, hostname, user, whether to use an identity file or not, and the deployment path. Personally I quite like this approach, as I find it neater and simpler.
To use it, once the file's created, in
deploy.php, I'll add a call to
serverList(), passing the name of the configuration file.
Then, in my server configuration, I only need to make a call to
stage(). The configuration file handles the rest.
There is one final option, which is a PEM file. But I'm not covering that in this series.