Making life easier with GIT SHAs in your HTTP Headers

Do you know what code is running on your servers? Perhaps someone deployed something in a weird way and circumvented your normal deploy-logging process. Maybe you suspect an application server didn't actually restart. Maybe you just want to know quickly because you're lazy.

My answer to this question has been adding the Git SHA of the currently running code to the HTTP headers of my app. By doing this, figuring out what's actually running is as simple as a:

 curl -I http://www.example.net | grep X-GitSHA

Accomplishing this is pretty simple, first, you'll want to run and store the output of:

 git rev-parse HEAD

in whatever directory your deployed code runs in. This is the fastest, and easiest way to determine the current SHA. In Rails this is easily done in an initializer or application.rb using something like:

 GIT_SHA = `git rev-parse HEAD`.chomp

Then, just make sure the constant gets inserted as a header. Again, in Rails you could do this with a before_filter in controllers/application_controller.rb

 headers['X-GitSHA'] = MyApp::Application::GIT_SHA 

And you're done! It should just work. Of course there's a million ways to actually do this.

Now that you have this info you can see what code is different between what's deployed and what's on say your master branch with a `git diff`:

PROD_SHA=`curl -I http://www.example.net | grep X-GitSHA | cut -d':' -f2` git diff $PROD_SHA...master

Or, you can see what the difference is in terms of commits messages rather than actual lines changed with `git show-branch`

 

PROD_SHA=`curl -I http://www.example.net | grep X-GitSHA | cut -d':' -f2` git show-branch $PROD_SHA master

Lastly, if you need the cache on a resource busted between deploys be it in either HTTP or Memcached, having a GIT_SHA constant available in your app makes it pretty easy to do. Note that this isn't great for a lot of situations where a file may NOT have changed between deploys.

Before PostgreSQL, Bruce Momjian wrote an SQL in Shell

Bruce Momjian is best known as a member of the PostgreSQL core team, what most people don't know is that in the early '90s, before he was working on Postgres, he wrote another SQL database.

And he wrote it in shell.

The result, SHQL is a pretty damn cool piece of software. I had an informal chat about it with Bruce a couple weeks ago at SCALE, and just had to write about it. The source is definitely a fun browse because not only is it a cool idea, it's the kind of software that belongs to a specific time. Asking Bruce how he picked shell, he mentioned that it was a language he knew, and that Perl just seemed like it was too heavy at the time.

What's immediately striking about SHQL is its completeness given its mere 760 SLOC. It supports, CREATE, DELETE, DROP, INSERT, SELECT, UPDATE, WHERE, PRINT, EDIT as commands, but has surprising completeness, including UNION and DISTINCT. It even supports a rudimentary form of views, through which you can do a basic sort of joining!

SHQL is not pure shell, it makes heavy use of both awk and grep. For instance, updating a table involves filtering the entire table through awk, directing the output to a tmp file, then replacing the current data file with the new one.

The source is definitely a fun browse, I'd recommend you download the file, and check out the README and demo as well!

One install note, on my ubuntu system /bin/sh has a few issues with it, I'd definitely use bash proper to run it. Also, be sure to mkdir -p ~/shql/MYDBNAME.