You’re in early stages of developing a Rails app and you decide that you want to go back and add some indexes to your tables. No need to create a new migration at this point, just add the indexes to the old migrations and run them again. After making the changes, you create a commit

git commit -a -m "Added missing indexes to tables"

Next you re-run all your migrations to get the indexes in there.

rake db:migrate:reset

At this point, you check git status and remember that now your schema file has changed. This probably should have been included in the last commit! Piece of cake.

git commit db/schema.rb --amend

You’ll be prompted to optionally change the commit message.

At this point git status will tell you that your working directory is clean and the changes to your schema were tracked in the same commit as the migration changes.

Butter.

Thankfully, a couple of technologies have come along and made my deployment process a whole lot easier.

1. Passenger

This was the big one. The Phusion guys’ “Hello World” app (as they called it) has really had a positive impact on the Rails community, and me personally. Suddenly my Rails (and Rack) web apps are first class citizens to Apache (and Nginx), which means I can just point a virtual host at the public directory and go. I had almost forgotten how good it feels to just drop some files in a directory and have Apache serve them.

2. Git

Ok, so maybe Subversion allows a similar workflow, but for some reason Git is one of those tools that is so much fun to use that it makes me think of different ways I can use it.

My Flow

How I deploy these days (when I’m not deploying to Heroku) is dead simple. I host my private Git repos using Gitosis, but the same would work with GitHub or any Git server.

Initial Setup

1. Clone the repository on production server.
2. Create database.yml and any other production-specific configs
3. Configure an Apache virtual host pointing to “public” folder of the repository

Deploys

1. locally:

   git push origin master

2. remotely:

   git pull origin master && touch tmp/restart.txt

I know what you’re thinking, “Wow, that is dead simple”. It’s even easier by using Capistrano to execute the remote commands. Here is an example Capistrano task from one of my Rails apps:

task :deploy, :roles  => :production do
  system "git push origin master"
  cmd = [ "cd #{root_dir}", "git pull", "touch tmp/restart.txt" ]
  run cmd.join(" && ")
end

This task can be extended to automatically install required gems, update Git submodules, migrate the database, and so on.

Other Benefits

Besides the simplicity and ease of deployment in this process, I have also enjoyed the ability to make edits in production and pull them back in to my development environment. And because my production environment has a complete history of code changes, it is trivial to revert commits that cause major problems.

This work flow is by no means a panacea. How do you handle deployment?

I recently needed to rename one of my repositories and couldn’t find any info on how to do it, so here is a walk-thru. I will demonstrate the steps of renaming a repository called “tk” to “show-time“.

1. Rename project in gitosis.conf and push changes

Before:

[group main]
writable = tk

After:

[group main]
writable = show-time

git push origin master

2. Connect to gitosis server and rename correct folder

cd /home/git/repositories
mv tk show-time

3. Change the remote reference in all repository clones

cd /src/show-time
git remote rm origin
git remote add origin git@example-git-server.com:show-time.git

Done and done.

The only thing worse than getting hacked is getting hacked and not knowing it (or worse yet, having one of your clients inform you). Often times an attacker needs to add and/or change files on your site to accomplish their goal. Wouldn’t it be nice if something could inform you of unauthorized changes? Enter Git.

I will demonstrate using Git for change notification on a WordPress install using Ruby, but you can apply this principle in many scenarios (hmm, /etc…?).

1) ignore folders/directories of no interest
We don’t want Git to track every file in the directory, so we’ll tell it which ones to ignore. Common choices are temporary directories, log files, and any file or directory that gets update frequently. Create a file called .gitignore in your site’s root directory. List the stuff for Git to ignore in it. It should look something like this:

wp-content/cache/*
wp-content/uploads/*

2) create new Git repository, add all files and execute first commit

git init
git add .
git commit -a -m "Initial Commit"

Now you’re set.

3) download & customize script
Git alone won’t check itself and email you. For this, we’ll need help of a scripting language. I wrote this little script in Ruby, but the same could be accomplished in Bash, Python, or whatever suits your fancy. You can write your own or download and customize the one I use:

wget http://jerodsanto.net/src/ruby/git_watch.rb
chmod +x git_watch.rb

The key to the script is where it shells out and runs the ‘git status’ command. If there have been changes to the repository that were not properly committed, ‘git status’ will not return “working directory clean”. The check is simple:

result = `git status`
unless result =~ /working directory clean/
  # set up email
  send_email SEND_TO, :body  => message
end

You’ll need to edit this file and change the SEND_TO variable to your email address. You can also customize the email that is sent by modifying the “send_email” function near the top.

4) schedule script execution

Now, lets make this script check the blog for changes once every hour. Edit your user’s cron configuration and add a line similar to this:

0 * * * * /scripts/git_watch.rb /var/www/mysite/wordpress

I put all my custom scripts in a /scripts directory on every server I administer. That way I always know where to look no matter what server I’m currently on. The script takes one argument, the directory to check for changes. Adjust your cron for your script and site locations.

But what about authorized changes? Simple. Commit them using Git and they won’t be triggered on.

For example, you install a new plugin to your blog and you don’t want your git_watch script to email you about it:

git add wp-content/plugins/github-widget/
git commit -a -m "installed github widget plugin"

The added bonus of this technique is you are creating a verifiable changelog of your site over time, complete with notes! An example from one of my sites:

git log
 
commit 109d30026118de089297a4d7fa56babff3677bdc
Author: Jerod Santo <jerod.santo@gmail.com>
Date:   Sat May 2 07:55:08 2009 -0700
 
    fixed bad php4 install and upgraded wp-cache
 
commit edc1e89c2cbf38ae1373f6b5cf03d29942399fd8
Author: Jerod Santo <jerod.santo@gmail.com>
Date:   Fri Apr 10 06:25:31 2009 -0700
 
    ignore sitemap changes

Plus, it is easy to trace the attacker’s steps if you do get compromised because you can see which files have been changed and what has been done to them (using the ‘git diff’ command). Once you diagnose the problem, you can simply revert to an old commit before the attack (you’re still vulnerable at this point, but at least your site is clean until you can patch it).

Enjoy!