How Can I Use Laravel Envoy or Deployer with SemaphoreCI?
This article was peer reviewed by Wern Ancheta and Viraj Khatavkar. Thanks to all of SitePoint’s peer reviewers for making SitePoint content the best it can be!
Test automation, continuous integration, and continuous delivery are quite widespread in the community now. This brought to life multiple services trying to make the process more enjoyable and less overwhelming for developers, so they can focus on delivering software instead of building/configuring tools to do that. One of those services is SemaphoreCI.
In this article, we’re going to cover how to use our own deploy scripts and tools to continue the deployment process after a successful test.
We will be using SemaphoreCI for continuous delivery and Deployer to push our code to the DigitalOcean production server. If you’re not familiar with Deployer, we recommend you check out this introduction.
Demo Application
We’ll be using a 500px application that loads photos from the marketplace. It was built using Laravel and you can read the full article about its building process here, and find the repo on GitHub.
Creating a Deployer Script
The way Deployer works is by us defining servers, and then creating tasks that handle the process of deploying the application to those servers. Our deploy.php
script looks like this:
<?php
require_once "recipe/common.php";
set('ssh_type', 'native');
set('default_stage', 'staging');
env('deploy_path', '/var/www');
env('composer_options', 'install --no-dev --prefer-dist --optimize-autoloader --no-progress --no-interaction');
set('copy_dirs', [
'app/commands',
'app/config',
'app/controllers',
'app/database',
'app/lang',
'app/models',
'app/src',
'app/start',
'app/tests',
'app/views',
'app/filters.php',
'app/routes.php',
'bootstrap',
'public',
'composer.json',
'composer.lock',
'artisan',
'.env',
]);
set('shared_dirs', [
'app/storage/cache',
'app/storage/logs',
'app/storage/meta',
'app/storage/sessions',
'app/storage/views',
]);
set('writable_dirs', get('shared_dirs'));
set('http_user', 'www-data');
server('digitalocean', '174.138.78.215')
->identityFile()
->user('root')
->stage('staging');
task('deploy:upload', function() {
$files = get('copy_dirs');
$releasePath = env('release_path');
foreach ($files as $file)
{
upload($file, "{$releasePath}/{$file}");
}
});
task('deploy:staging', [
'deploy:prepare',
'deploy:release',
'deploy:upload',
'deploy:shared',
'deploy:writable',
'deploy:symlink',
'deploy:vendors',
'current',// print current release number
])->desc('Deploy application to staging.');
after('deploy:staging', 'success');
You should read the Deployer article if you’d like to learn more about what this specific script does. Our next step is to set up a SemaphoreCI project. Please read the crash course article if you’ve never tried SemaphoreCI before, and do that.
Setting up Deployment
To configure the deployment strategy, we need to go to the project’s page and click Set Up Deployment
.
Next, we select the generic deployment option, so that SemaphoreCI gives us the freedom to add manual configuration.
After selecting automatic deployment, SemaphoreCI will give us the ability to specify deployment commands. The difference between manual and automatic, is that automatic deployment is triggered after every successful test, while manual will let us deploy any successful commit.
We can choose to include the deployer.phar
in our repo as a PHAR file or require it using Composer. Either way, the commands will be similar.
If we chose to deploy the application using SSH, SemaphoreCI gives us the ability to store our SSH private key on their servers and make it available in the deployment phase.
Note: SemaphoreCI recommends that we create a new SSH key specifically for the deployment process. In case someone stole our keys or something, we can easily revoke it. The key will also be encrypted before storing it on their end.
The key will be available under ~/.ssh/id_rsa
, so the identityFile()
can be left at the default.
Push to Deploy
Now that everything is set up, we need to commit some changes to the repository to trigger the integration and deployment process.
// Edit something
git add .
git commit -am "Updated deploy"
git push origin master
If something went wrong, we can click on the failed deploy process and see the logs to investigate the problem further.
The above screenshot is a failed commit due to the php artisan clear-compiled
command returning an error because the mcrypt
extension wasn’t enabled.
Note: Another neat trick that SemaphoreCI provides is SSHing to the build server to see what went wrong.
Other Deployment Tools
The same process we used here may be applied to any other deployment tool. Laravel Envoy, for example, might be configured like this:
@servers(['web' => 'root@ip-address'])
@task('deploy', ['on' => 'web'])
cd /var/www
@if($new) {{-- If this is the first deployment --}}
git init
git remote add origin repo@github.git
@endif
git reset --hard
git pull origin master
composer update
composer dumpautoload -o
@if($new)
chmod -R 755 storage
php artisan storage:link
php artisan key:generate
@endif
php artisan migrate --force
php artisan config:clear
php artisan route:clear
php artisan optimize
php artisan config:cache
php artisan route:cache
php artisan view:clear
@endtask
And in the deployment command step, we would install and run Envoy:
cd /var/www
composer global require "laravel/envoy=~1.0"
envoy run deploy
That’s it! Envoy will now authenticate with the key we’ve added and run the update command we specified.
Conclusion
CI/CD tools are a great improvement to a developer’s workflow, and certainly help teams integrate new code into production systems. SemaphoreCI is a great choice that I recommend for its easy to use interface and its wonderful support. If you have any comments or questions, please post them below!