Posts Tagged ‘git’

Using git to sync configurations between two computers

Monday, April 13th, 2009

I have two machines that I use for my development work: a 24″ iMac and a MacBook Air (It is so choice. If you have the means, I highly recommend picking one up. _Bonus points for quote identification_). Naturally, doing any work spread over two machines leads to all sorts of problems: Inconsistencies in development platform, files, data, code and just the general configuration of the machine. Thankfully, there exists a number of solutions to these problems.

DropBox

DropBox is simply file synchronisation done right. You install it, drag the files you want to have synced between two computers into the Dropbox folder, and BOOM, it copies everything up to their server, and when you set it up on the second computer, copies everything back down again. After the initial sync, which can take quite a while if you’ve got lots of stuff, it’s pretty much seamless. Create, or make a change to, a file on one computer, and before you know it, it’s available on the other computer.

Need access to those files from another computer, or even from your phone? No problem, they have a web interface that give you full access to all of your “synced” files. Simple.

To add a lovely cherry to the ice cream sundae that is DropBox, they also have versioning. That means if you make a series of dunderhead changes to a document, you can just rollback to the last good copy. Awesome.

Git and GitHub

For the longest time (mostly while I was still working on Windows) “Source Control” was some mystical mumbo jumbo that only people in large companies needed to worry about. Of course, that was mainly because at the time the options for Visual Studio only included Microsoft SourceSafe, which is perhaps some of the crappiest, most unusable software ever foisted on the unsuspecting public by a company with a long history of foisting crap on the unsuspecting public.

Once I switched to MacOSX and started working with Rails, it became clear that all source control systems weren’t created equally. Subversion seemed to be the choice of the community, so I loaded everything up onto my own SVN server. A world was opened up to me, and I could code with wild abandon, safe in the knowledge that I could rollback with no danger. Of course, that was the ideal world, but the basic approach worked. I created branches, tagged releases and deployed sites from SVN.

As with most things, people started grumbling about SVN and some of it’s shortcomings: difficulties in merging different code branches, no distributed repositories and some general discontent. Git was the solution, and the rails community just jumped ships in the middle of the night. Before you knew it, everyone was using Git, and also GitHub. I won’t go into the specifics of why this combo is so good, except to say that if you’re not using git, well, good day to you sir.

git and config_files

In addition to using git to store your development work, you can also use it to manage system configuration files. I found the wonderful config_files. It’s a collection of shell, git, vim and irb configuration files. So? How does that help?

A great feature of git, and github in particular, is that you can “fork” a repository. You effectively copy someone else’s repository, and you can then make all the changes to it you want, without affecting the original. If you want to let other people know about your changes, you can send the original developer a “pull request”, and they can grab your changes, and incorporate them, or not.

So, fork the config_files repository, and then clone it to your own system. Run the “install.sh” script, which basically just sets up a series of symlinks in your user directory. These symlinks point to the files in the git repository. You make any changes you want to the repository and commit them up to github. Then do the same on your other computer, and bingo, you’re synchronising your configuration between machines.

And why would you want config_files? Well, you get some great all round system setup tidbits, but my favourite bit is how it prints the current git branch as part of your prompt, saving you the need to try and work out what you’re in the middle of doing.

Tasty.

Freezing Rails with Git

Thursday, June 12th, 2008

Now that the Ruby On Rails team has moved the codebase over to github, some of the standard rake tasks aren’t working the way that they used to. When it was on SVN, it was possible to type

rake rails:freeze:edge TAG=rel_2-0-1

and the appropriate version would be copied into your vendor/rails directory.

Now if you do that, rake downloads a zip of the edge release. Which is fine and all, but sometimes you don’t want to be on edge … like in any production site.

So, I found a screencast that goes through the process, but I thought I’d actually put the text into a post, mainly for my own reference more than anything else.

$ rails path_to_app

$ cd path_to_app

$ git init

$ git submodule add git://github.com/rails/rails.git vendor/rails

At this point, git will effectively clone the repository, so that you can then choose one of the branches to “freeze” to. Type “git tag” to get a list of all the available tagged branches. Choose the one you want and type

$ git checkout v2.1.0

And that’s it. Slightly more involved than the old way, but still none too shabby.

Getting Rails, Git and Capistrano to work on a Joyent Accelerator

Tuesday, April 8th, 2008

After several days of repeatedly smashing my head into both a metaphorical and an all too real brick wall, I seem to have managed to get git and capistrano working happily together on my Joyent Accelerator. I’m also using github for my git hosting, which threw up it’s own little challenge mid-way through the entire process.

Now, I should probably also say that I already had my site up and running using subversion, capistrano and my accelerator, so this article isn’t necessarily going to help with getting everything setup the first time. For that, you probably need to read this wiki entry.

Things You Will Need

  • A github.org account
  • A dedicated Joyent Accelerator (I have no idea how to do all of this on a shared accelerator. Sorry.)
  • Also, I’m really only talking about RubyOnRails apps here … not too sure how applicable a lot of this is to other frameworks (it will probably help at least.)

Getting started

Assuming that you have your project in a git repository, and have a github account (and obviously an Accelerator) we can start.

Compiling git on your accelerator

Unfortunately, the first step in the process was, for me at least, a total nightmare. I’m not the biggest unix-head by any stretch, but I can do some basic tasks with a degree of proficiency. Unfortunately, I went into a dark place trying to get git compiled. One thing to note is that I’m talking about setting up the git client here, not a git server. Because capistrano executes scripts on your remote server, you need to have a copy of the client software setup for capistrano to call.

So what did I do? There are a couple of helpful threads on the Joyent Forums:

Hopefully those threads will put you onto the path of successfully compiling and installing git onto your Accelerator.

Setting up SSH keys with github and your accelerator

When you setup your account on github, you need to setup an SSH key for authentication. github has a really good tutorial on how to do this. I have a user defined on my accelerator that my website “runs” under, so what I did was to create a key for that user which gets stored into the ~/.ssh directory. I then added the contents of the id_rsa.pub key to my github account, which allows that user to access the repository.

Another tip: don’t forget your passphrase. It’s needed in the next step.

Configuring capistrano

Assuming that you have your capistrano deploy.rb file setup as outlined here there are a few changes that you will need to make to get things working with git.

I’m using Capistrano 2.2 at the moment. I don’t think it will work with earlier versions because of the relatively new git support.

Here’s my deploy.rb file:

  require 'erb'
  require 'config/accelerator/accelerator_tasks'

  set :application, "website"
  set :repository, "git@github.com:your_username/website.git" 

  default_run_options[:pty] = true
  set :domain, 'XX.XX.XX.XX' #Your Accelerators public IP address
  set :deploy_to, "/var/www/apps/#{application}"
  set :user, 'website_account_username'
  set :scm, :git
  set :scm_username, "github_username"
  set :scm_passphrase, "your passphrase here" 

  role :app, domain
  role :web, domain
  role :db,  domain, :primary => true

  set :server_name, "url.for.website"
  set :server_alias, "*.url.for.website" 

  # Example dependancies
  depend :remote, :command, :gem
  depend :remote, :gem, :money, '>=1.7.1'
  depend :remote, :gem, :mongrel, '>=1.0.1'
  depend :remote, :gem, :image_science, '>=1.1.3'
  depend :remote, :gem, :rake, '>=0.7'
  depend :remote, :gem, :BlueCloth, '>=1.0.0'
  depend :remote, :gem, :RubyInline, '>=3.6.3'

  ################################
  # Some tasks for the old server
  ################################

  task :after_deploy do
    # tasks to run after deploy
  end

  ################################
  # End tasks for the old server
  ################################

  deploy.task :restart do
    accelerator.smf_restart
    accelerator.restart_apache
  end

  deploy.task :start do
    accelerator.smf_start
    accelerator.restart_apache
  end

  deploy.task :stop do
    accelerator.smf_stop
    accelerator.restart_apache
  end

  after :deploy, 'deploy:cleanup'

It appears that the important line here is ’ default_run_options[:pty] = true ’. This means that capistrano can respond automatically for the request for the SSH Key passphrase that github replies with when you try to clone the repository.

If everything is working, you can type ‘cap deploy’ and it should all deploy nicely. If you get this error:


[err] Permission denied (publickey).

then there’s a problem with your SSH key and your settings on github. Make sure the key you copied into your github account is the public key for the SSH in your .ssh directory.

Hopefully, you’ll be up and running. If you have any tips, recommendations or corrections, leave a comment.