5 years ago

Envoyer and Travis CI - Using deployment hooks

Posted 5 years ago by olimorris

In the post below I outline how you can use Travis-CI to trigger deployment in Envoyer on a build that passes.

Since it first launched, I've been a massive fan of Envoyer.io. You can't put a price on peace of mind and with zero downtime, health checks and heartbeats, it serves my needs perfectly. It's also a wonderful showcase for what Laravel 5 can do.

For myself, the one piece of the production deployment puzzle that I hadn't addressed was the link between continuous integration (CI) and zero downtime. Envoyer is smart enough to ensure that when I push to Github, deployment will take place automatically. It's also incredibly smart to only symlink to the new release directory when the deploy has happened successfully. However it cannot of course, prevent deployment if I screw up my code or a rogue Composer package introduces some anomalies and throws errors into the production environment...and why should it. It's not the purpose for which it was designed for.

Now I acknowledge that we're lucky in the world of Laravel. We have Homestead and Laravel Forge. You could quite easily do without CI and still sleep tight at night after pushing to Github. However, there have been two occasions (during the L4 to L5 upgrade process) whereby my site worked just fine on Homestead but didn't work as planned when I pushed up to Forge. Since then, I've become a big fan of Travis-CI. So this morning I set out to see how easily I could make Travis talk to Envoyer.

Within Envoyer, Taylor has given us a nice deployment URL which we can use to trigger our deploys (you can just type it into your URL bar to start deployment if you like). Knowing how Travis allows for webhooks, I set about solving my little problem - and it turns out it's super easy so I thought I'd share it with the community.

  1. I'm assuming you're familiar with Travis-CI and you have an existing travis.yml file and some tests that run on deploy
  2. In Envoyer, click in the 'Deployment Hooks' tab and copy your URL under the 'Deployment Info' section
  3. Now, we don't really want to display the URL outright in our travis.yml file. Some bugger could get hold of it and just continually keep forcing requests and trigger deploy after deploy after deploy. To prevent this, we can utilise Travis' own encryption and we can do so using the Travis Command Line Tool (see: https://github.com/travis-ci/travis.rb#installation).
  4. Assuming you have the tool installed (which takes 30 seconds and is straightforward), CD into your local repository and run the following command:
travis login

and type your Github login in. Then you can run the following command, pasting in your deployment URL within the quotation marks:

travis encrypt "https://envoyer.io/deploy/WHATEVER_MY_KEY_IS" --add notifications.webhooks.urls
  1. This will add the encrypted Envoyer deployment URL to the end of your travis.yml file - protecting and preventing gnarly little so and so's from screwing with your deploy
  2. This is all good however we've not actually told Travis to only notify Envoyer when our build passes. By default Travis will still trigger deployment in Envoyer on failure. To address that, add the following below the encrypted webhook:
on_success: always
on_failure: never
  1. That is all you need to do so your final travis.yml file, with an Envoyer webhook should look like this:
    on_success: always
    on_failure: never
  1. Oh and be sure to turn off push to deploy in Envoyer or that will render steps 1 to 7 as absolutely useless :)

So wonderfully trouble free and all without the need for a complicated Travis-CI service provider. Credit to Taylor for making Envoyer so easy to use and so damn robust.

Please sign in or create an account to participate in this conversation.