Deploy your Rails 3 applications à la Heroku with Inploy

I’m not a fan of Heroku‘s deployment way, but I know that many people is and that many of them don’t know that with Inploy you can deploy your Rails 3 applications in a similar way.

Thomas Ritz contributed with Inploy creating a template called rails3_push. The template modifies Inploy so it creates a repository in the server on setup and pushes to it on every update, being followed by all the tasks that it executes by default on every deploy.

In order to use this template, like any other, you must specify it in the deploy.rb file:

template = :rails3_push
application = "tweerer"
hosts = %w(...)
...

After that, to setup your server and to deploy to it, you can execute respectively the following commands:

inploy setup
inploy

If you appreciate this work, please consider to recommend me at Working With Rails and to follow me on Twitter.

Summary of new features in Inploy

After announcing Inploy 2 months ago, several people colaborated with it and now it has more features, the ones I will expose in this post.

First of all, I want to thank these people for the contributions:

Andy Shen
Carlos Brando
Douglas Campos
Erik Dahlstrand
Joris Troost
Josh Owens

If you upgrade Inploy today and do nothing else, the two features you will automatically earn out of the box are:

control of submodules

This functionality initializes/updates the Git submodules on each deploy, so that the code is always updated without the possibility of forgetting.

Hoptoad notification

For those who use Hoptoad, Inploy will notify the tool on every code update, sending the environment and the revision code.

Besides the new features mentioned, Inploy now also has the following optional settings, which can be specified in the deploy.rb file:

sudo

Case you want to run the commands in the server as sudo.

server (Unicorn support)

Inploy works now with Unicorn, too, being Passenger the default server.

environment

Inploy works with production environment as default, but now we can use another one, like staging.

branch

Such times we have a branch with the configurations of our deploy and we want to use it, we can do it with the branch option.

ssh_opts

If you want to connect to the server using some ssh parameter, we can specified it in this option.

Here’s an example of how to use the options mentioned:

if ENV['environment'].eql? 'staging'
  deploy.ssh_opts = '-A'
  deploy.server = :unicorn
  deploy.environment = :staging
else
  deploy.branch = :deploy
  deploy.sudo = true
end

Please consider to recommend me at Working With Rails.

Rails deployment made easy with Inploy

After working in some systems made in Rails, Capistrano became one of the things that began to bother me more and more. I tried to find other alternatives, including Vlad, but none satisfied me, so I decided to create a solution and called it Inploy.

Before Capistrano fans crucify me, I wanted to let it clear that I don’t think Capistrano is a bad tool, just that it’s bad for my needs, which are much simpler than Capistrano can attend.

One of the things I don’t like about Capistrano is that it creates a lot of folders, one for each release. Some people argued with me that they are useful when you want to rollback a release, but that never happened to me, as never happened with most of the people I talked with. The rest of the people told me that in some circumstance they had to rollback a deploy, but the circumstance was that the deployed code broke the build.

Inploy uses Git, so in case we need to rollback our deploy to a version, we can use git reset. Of course this solution is more limited that the one that Capistrano uses, but it’s a solution to a problem that probably should never occur, a problem caused probably by bad practices in the development.

As a consequence of Capistrano strategies, they deploys are a little slow for my taste. I know there are some configurations that can speed up the process, but to configure is a thing I don’t want to do. I want to use a tool that works the best way by default and in most cases, the best way to a fast deploy is the simplest one: git clone in the setup and git pull in the update, the same that Inploy does.

Speaking about defaults, it’s very annoying to me having to define in Capistrano how to restart the server, how to clean the cache and what tasks it should rake, like more:parse and asset:packager:build_all. Inploy tries to solve this problems by executing common tasks by default, being smart enough to identify what tasks it should rake and in which order. The idea behind the plugin is that you shouldn’t worry about how to deploy that new tool you’re using, that things just work without the possibility of something going wrong.

Another advantage from Inploy over Capistrano for most cases is that it just have one way to deploy and its called update. This task updates the code, migrates the database, does some other tasks and restarts the server. It makes not sense to me to update the code without running migrations. In all teams I worked with, everyone could deploy the application and in most cases someone executed cap deploy instead of cap deploy:migrations. I know this is a human error but I prefer to use a tool that doesn’t let people make mistakes.

A need I had with deployment tools is that it could work both remotely and locally. I worked in a project that was delivered to a foreign client and the people responsible of updating the application in each release couldn’t do it otherwise that by connecting to a server and running a script. All of them used Windows and were used to work with Java systems that required them to access a machine, replace a war file and execute some commands. In that opportunity, the solution was to create a deploy.sh file in the root folder on the application. This file was executed by somebody from the client every time they needed to update the application.

The problem mentioned above doesn’t happen with Inploy, as it can be run both remotely or locally. When running remotely, the only only thing it does is to connect to a list of servers and run the tasks like being locally logged. It’s because of this that Inploy is delivered as a plugin, so it’s available in all environments.

As today, Inploy will only work for you if you’re working with Git and Passenger.

To install Inploy you can execute:

script/plugin install git://github.com/dcrec1/inploy.git

On installation, Inploy will write to a file in config/deploy.rb. This file is read by the plugin and it should be something like this:

deploy.application = "inploy"
deploy.repository = 'git://github.com/dcrec1/inploy.git'
deploy.user = 'dcrec1'
deploy.hosts = ['hooters', 'geni']
deploy.path = '/var/local/apps'

After that, we’re ready to execute the tasks that the plugin has:

rake inploy:local:setup
rake inploy:local:update
rake inploy:remote:setup
rake inploy:remote:update

I created a short video in which I demonstrate how to use the different tasks of the plugin. In the video I’m inside the Signal project, which already has Inploy installed and I remove it along with the configuration file to demonstrate how easily it is to install and configure it. After that I execute a remote setup and then a remote update. We can see in the video that the commands that Inploy runs are logged with the corresponding outputs and that config/*.sample files are renamed to config/*, another feature of Inploy. In the second part of the video a local update is ran and then deleted the repository, cloned and executed another setup, this time locally.

Deploy easily to Locaweb with Inploy from Diego Carrion on Vimeo.

More details about the plugin can be obtained in the official Inploy repository, where I’ll try to keep the README up-to-date. I hope it’s clear the way that Inploy works, but just in case, looking at the code is an option to eliminate doubts. The code is quite small (50 LoC moreless) and also self explanatory. Follows an snippet:

def local_setup
  copy_sample_files
  create_folders 'tmp/pids', 'db'
  run "./init.sh" if File.exists?("init.sh")
  after_update_code
end
 
def remote_update
  remote_run "cd #{application_path} && rake inploy:local:update"
end
 
def local_update
  run "git pull origin master"
  after_update_code
end
 
def after_update_code
  install_gems
  migrate_database
  run "rm -R -f public/cache"
  rake_if_included "more:parse"
  rake_if_included "asset:packager:build_all"
  run "touch tmp/restart.txt"
end

I wish this simple code motivates people to contribute with the project and make it smarter.

If this plugins helps you, please consider to recommend me at Working With Rails.