Posterous theme by Cory Watilo

Managing Production and Development Ruby Environments with Git

This is an experiment for the most part, but due to blog postings such as this one, I'm led to believe that you can manage and distribute a particular Ruby environment by using Git.

While the idea of distributing an application via Git might seem at odds with Windows' application management (MSI's, Programs and Features Control Panel), it's believable that it might well be possible with applications such as Ruby, which aren't tightly coupled with Windows in the first place. Ruby is primarily developed for a Unix environment in the first place, and although there is Windows integration via RubyInstaller, there really isn't anything in the package itself that expects more than a working shell environment. I'm guessing that RubyInstaller does little to Ruby itself, instead just wrapping with an installer and uninstaller and offering to add Ruby to your path and associate files with the executable.

Putting binaries under version control is usually another point of contention, but that shouldn't be a problem either as long as we're talking about a uniform Windows environments. The Ruby executables installed in one environment should work fine whether distributed to XP, 7, 2003 or 2008. The only relevant distinction should be the 32- or 64-bitness. That leaves the rest of the files, which are primarily the installed gems and any native files they rely on. Again, the bitness is the only issue there. Since the gem files are primarily source code, version control makes fine sense there.

So I'm giving it a shot.

What's the point of doing this? Just as important as the code used for our Spree store is the Ruby environment that runs it. If either break, the store won't run. And we don't sell. And we don't eat. The source code for the store is guarded jealously with Git. Why shouldn't the Ruby environment as well be guarded so?

While that's an important reason to consider using Git on the Ruby environment, that goal can be accomplished via other means (backups, shadow copies). However, running shadow copies on the system drive poses some issues of its own. We only really want to track one relatively-unchanging folder, but shadow copies will track the many automatic system changes that occur as well. This might argue that the Ruby install should be moved to another directory, but that's a different discussion. Backups are difficult to set up and aren't always done, even though they should be. Again, another discussion.

However, there's another purpose which suits version control that isn't taken care of by the other solutions to the backup issue. That purpose is synchronization of the development environment. While the developer may develop and test, thinking that his installation exactly matches what will be used in the final production environment, that assumption is easier said than done. Even if you install exactly the same packages in production and development, there is inevitable drift as experiments are tried, upgrade processes face and resolve issues, and mistakes are made with installs. Git provides a way to mirror the production environment to any developer in a consistent way.

So I'm creating a github repository for the Ruby install on Mojo-a, which I will clone to my development machine and use when testing code which is intended for deployment.

I'll be writing another post on how to manage this environment side-by-side with the other Ruby environments I also want to be able to use on my development machine.