Day: November 2, 2018

Some notes on a basic Capistrano deployment

My notes when starting out with Capistrano.

Capistrano lets you automate deploys. It lets you specify some settings in an organized fashion. It then logs into your server and runs the scripts associated with your settings – whether they are built into Capistrano or custom defined by you. Things like downloading a latest copy of the code, running migrations, cleaning up, rolling back a failed deploy etc can all be done by either specifying a few settings or writing a “task” for Capistrano to run at some point in the deploy.

In our case, we have a simple, static website – a handful of HTML, CSS, and JavaScript files as well as a folder full of images and other static assets. Thus far, we have had to manually upload the files to the server when we change something. Even with the simple setup we have so far, manually uploading to the server can be problematic: I’ve sometimes forgotten to upload all the files. At other times I’ve forgotten to type all the commands on the server to make sure the permissions on the files are correct. If I automated this, then that would be awesome!

A few pre-requisites:

  • Capistrano needs Ruby (the language). Using the Bundler gem is nice to manage your ruby gems, although not mandatory. I use Bundler. If you are using Capistrano in Ruby on Rails then Bundler is kind of a requirement anyway.
  • Capistrano will need some way to get the latest version of your code. In our case, we’ve decided to host a git repository on the same server.
  • For any environment, Capistrano runs all commands as one user. You need to make sure that your local users’s ssh public key is in the authorized_keys file in the remote user’s .ssh directory. This will let capistrano ssh into the server without asking for a password.
  • There’s some support for interactive shell (where the system asks for some data to be entered) but I haven’t explored this. It is simpler to make sure that the permissions on the server are setup correctly. In our case, we’re going to download files from the git repo to a folder, update their permissions so that they belong to the www-data group, and then move them to the appropriate public_html directory. That said, this might be a dumb way to do it when we might be able to deploy code directly to the appropriate directory and then update symlinks to the latest folder. The latter functionality is built into Capistrano.

Some things to keep in mind when writing rake tasks:

  • Make sure the file ends with a .rake extension or Capistrano / Rake will ignore it.
  • The “desc” statement is just a statement, even though it is associated with whatever comes after it. No “end” statement is associated with it.

That is all for now. More to come if I think of it.