On my other blog, I recently covered how to install Ruby 1.9.2, Rails 3.0 and a framework called Pik. Pik is a Ruby Version Manager (RVM) for Windows, making a huge difference when you want to run multiple different versions of Ruby such as 1.8.6 and 1.9.2. However, I’ve recently found another use for the framework.
While the 7digital code-base (where I currently work) is based around C# and ASP.net, we are using Ruby to help us manage builds, deployments and more importantly our acceptance tests. One of the issues we faced with Ruby was making sure that our dev machines, build agents and servers were all running the same set of gems. Having to manually install\update gems on each environment became too time consuming, new starters spent too long configuring their environment and as a result making changes became hard and our Ruby progress slowed.
As it happens, the team have been distributing generic libraries, MSBuild files and configuration files for a while without any problems via TeamCity. Within subversion we have a directory to store various artifacts with TeamCity waiting for changes. When a change occurs, the directory is automatically checked out on the different environments all managed by TeamCity. It’s a great way to distribute files.
It turns out that this also solved our Ruby problem. Every time we want to update a gem we can upgrade our local machine and commit the changes, which will then automatically be replicated. The problem is, you can only have one version of Ruby in your path at any one point in time. This makes it much harder to hack play work with gems which I don’t want to be shared.
This is where Pik comes in.
While Pik manages different ruby versions, it works in exactly the same way when the Ruby version is the same but in different independent locations. This allows you to have a different set of gems depending on your requirements – such as local and production versions.
After installing, it will detect your default installation (our teamcity version lives in C:\TeamCityBuildTools). However, I can also add a second Ruby location even if it’s the same version:
>pik add C:\ruby\bin
This version appears to exist in another location.
If you’d still like to add this version, you can.
Enter a unique name to modify the name of this version. (enter to quit)
The unique name allows it to be accessed later – I called mine 186-local. By default, pik will still point to my default original location.
When I list all the installations, it knows about both the default TeamCity distributed runtime together with my own personal installation of 1.8.6.
186-local: ruby 1.8.6 (2007-09-24 patchlevel 111) [i386-mswin32]
186: ruby 1.8.6 (2007-09-24 patchlevel 111) [i386-mswin32]
However, I can switch to my local installation with a single command.
>pik switch 186-local
This will change my path variable, together with the gems being used and other tools such as rake, cucumber and rails being executed.
I can now prototype, play and hack without touching the shared distribution and potentially affecting others on the team. Pik also means I can install 1.9.2 and any other version of Ruby, but when it comes to working on the code-base and pairing with people, I can quickly switch to the standard set of gems and version of Ruby with a single command.
WARNING! HERE BE DRAGONS!
Having said that. If you “accidentally” have the wrong Ruby version set in your pik config, you will have to use the “SVN revert” feature before you completely mess everything up by mistake. Yes, I made this mistake and yes, I’ve used this feature. Luckily I realised, but it’s something to keep in mind.
Aside from that, I really like how Pik allows me to have multiple independent Ruby environments on my same machine. Combine this with the way we are distributing our generic libraries and Ruby environment, allowing for a nice balance of flexibility and reliability.