Tag: deployment

Deployer — Deployment tool for PHP

deployer

Deployer is yet another tool for deploying PHP projects.   It looks to have more similarities with Laravel Envoy and phake, than with Robo.li, of which I am a new and growing fan.  But I thought I’d throw it into the mix here, just in case I’ll change my mind in the future.

Robo – Modern Task Runner for PHP

robo

There is a whole lot of ways to build and deploy web applications these days.  I’ve done my own circle of trials and errors and have some very strong opinions on which ones are good, which ones are bad, and which ones are ugly.

My most recent discovery was Robo – a modern task runner for PHP.  I’ve been pushing it to one of those weekends, where I have nothing better to do, to trying it out.  And today I did.  Not just tried it out, but replaced a part of our infrastructure, which was previously running on Laravel Envoy.

Robo is very nice.  On one hand, it’s simple and straight forward and is very easy to get you started with.  On the other hand, it provides quite a bit of functionality to help you with the build and deploy process.  Here are some of the things that I love about it:

  • It’s PHP!  Which makes it perfect for PHP projects, the kind I’m dealing with most of my time.  No need to translate your PHP into XML (hey Phing), or into a weird rake/capistrano like syntax.
  • Instant support for command line arguments and their validation, help screens, ANSI colors, and the like.  Honestly, I don’t know why we are still fighting these things in 2016.
  • Transparency.  You install robo with composer, create your RoboFile.php, and you are done.  All public methods of the class in the RoboFile.php will be available as robo commands.  All parameters of public methods are populated by the command line arguments.  There is no black magic to it.  All that is executed is whatever you write.
  • Extensions (or Tasks and Stacks).  There are a few to utilize already (SSH, git, and more).  And it is trivial to write your own and share them with composer/Packagist.  That’s one of the things that is difficult with our current build setup based on phake (hence our phake-builder).

Things I don’t like (remember I have been using Robo for just about 3 minutes):

  • Logging.  While it’s trivial to add logs into the RoboFiles using your choice of the logging library (monolog is awesome), I haven’t found a way to get all the output after the command execution.  For now, I’ve wrapped the Robo run into a shell script, which collects all outputs and sends it by email into our deployment archives storage.
  • Remote power.  Robo has some very cool tasks and stacks for local work.  But I haven’t found a way to utilize them when using Robo’s SSH task.  This slightly spoils the clean remote commands with sprinkles of bash, which I would love to avoid.

Overall, it looks like a very nice and elegant system and I’ll probably be using it for much more.  Once I get a bit more comfortable with it, I will probably replace our phake-builder setup with Robo.

If you are looking for a good tool to use for your build and deploy needs, give it a try.  You’ll probably like it a lot.

Deploying with git

Git is an excellent version control, but it’s more than just that.  A lot of people use it to deploy their projects as well.  Most suggestions (for example, this tutorial from Digital Ocean) around the web employ the post-commit (or other) hooks to push the code to a remote server.  While this works well, I prefer to do it differently.  I like the pull model better, where the deployment is triggered outside of git, and relies on git to fetch the code updates and run some sort of a build script, which handles database schema changes, cache resets, filesystem permissions, etc.  Such approach also allows to limit remote access to the servers (especially the production ones), and separate responsibilities of a developer and a deployer.

With the many pull, merge, fetch, and update options that git provides, it is sometimes difficult to choose what’s the right set of commands to use.  I’ve figured it out via a rather lengthy trial-and-error process.  But if you don’t want to go through all the pain of that, here’s a nice blog post that tells you exactly how to do that.  I’m copy-pasting the commands here just for the future reference.

cd "${DEPLOY_TREE}"
git fetch --all
git checkout --force "${TARGET}"
# Following two lines only required if you use submodules
git submodule sync
git submodule update --init --recursive
# Follow with actual deployment steps (run fabric/capistrano/make/etc)

And I suggest you read the full article for the explanation of why this is a better way and what are some of the issues with other strategies.

 

Bitbucket Pipelines Beta announced

BitBucket blog announces Pipelines Beta (coincidentally after I’ve spent about a week playing with Jenkins).  These guys are dropping their Bamboo Cloud CI solution and instead provide this:

It looks a lot like TravisCI, but on steroids!  Very good news!