40. (with egg)

Today I paired with a coworker to install SwitchTower to handle our automated application deployment for our Ruby on Rails projects. All in all it seems to work pretty well, though it took all day to install and there appear to either be several confusing bugs. It’s also possible that we missed some documentation, since today is the first day either of us have installed SwitchTower.

Here is a general log of our installation process:

9am – We hit the link above and started reading. The recipe concept looked pretty strait forward so we dove right in. Since our newly minted Subversion server, a Linux box, didn’t have Rails installed, we decided to try using SwitchTower on our Windows development machine. This was our first mistake.

10am – Installation via Gems was a breeze. We followed the instructions and “SwitchTowerized” our project, which created 2 new files in our file system:

• config/deploy.rb
• lib/tasks/SwitchTower.rake

We edited deploy.rb, filling in all of our configuration info, and tried to deploy to our offsite demo box.

12pm – After a couple of hours debugging SwitchTower and Rake on Windows we broke for lunch. Rake could not find the tasks specified in config/deploy.rb, and running the default rake deploy did nothing. We fiddled with SwitchTower.rake a bit and attempted to explicitly reference deploy.rb, only get generate some unhappy errors:

rake aborted!
undefined method `set’ for main:Object
./config/deploy.rb:13

“set” is used to set variable for SwitchTower, such as the :deploy_to directory for your application. It seemed bad that this was not working, and after reading some stuff about how SwitchTower only begrudgingly works on Windows, we decided to install Rails on the Linux server that would be running this anyway.

1pm – Luckily my pair knew a lot about compiling and installing apps on Linux using gcc and make, because we had all kinds of problems. From our Fedora Core 3 machine:

• gcc was not installed: we installed it using yum install gcc
• Rails install failed with the following

/usr/local/lib/ruby/site\_ruby/1.8/rubygems/custom\_require.rb:18:in require__': 
    No such file to load -- zlib (LoadError)

After some searching we found that we needed zlib-devel, and thus we installed it using yum install zlib-devel

• We recompiled and installed ruby, rails, gems, and SwitchTower, only to be stopped by openssl

/usr/local/lib/ruby/site\_ruby/1.8/rubygems/custom\_require.rb:18:in require__':
    No such file to load -- openssl (LoadError)

We rolled the dice and did a yum install openssl-devel, since grabbing the –devel version worked for zlib. It worked.

• And now, with the utmost confidence: Recompile… ruby… rails… gems … SwitchTower… ack! ack! md5… digest… ack! ack! ack! Try to install md5-devel… nothing! ack! ack!…
• Oh well let’s try again just for fun: … Recompiled… ruby… rails… gems … SwitchTower… bingo! Sometimes you just have to reinstall. Linux zealots are hereby banned from making fun of Windows for this.

3pm – After all of that noise we were finally able to get SwitchTower to talk to our demo box and at least attempt to deploy our app. This is where found that when SwitchTower performs checkouts from version control, it does this from the server running SwitchTower. It seems obvious now, but we were confused at first. Having the SwitchTower server perform all of the source control work is much better than installing Subversion on a bunch of servers.

All was not working but seemed to be well on its way. Here are the final steps:

• We implemented the restart task as suggested in the documentation to bounce our server
• Since SwitchTower changed our directory structure a bit, namely adding a current directory in the middle of things, we updated lighttpd.conf as needed.

5:30pm – Everything is working. In addition to normal config changes, we had a few SwitchTower-specific problems, which are either bugs or misunderstandings on our part:

• SwitchTower did not create the “shared” directory by default as stated in the documentation. More importantly, the shared/log directory was not created automatically, which is problematic since SwitchTower created symbolic links to this directory.

Setting the shared_dir variable explicitly in the deploy.rb file did not fix this. As a result the application would not start until we manually created the ourapp/shared/log directory.

• According to the documentation, we have many after_ and before_ tasks. Thus we attempted to work around the non-creation of the shared_dir by implementing after_setup in config/deploy.rb.

No dice – it was never executed; maybe we needed to explicitly call it somehow, be we haven’t figured it out yet (please let me know if you know how). We ended up implementing after_update_code instead.

Note that we used the old >/dev/null 2>&1 || true trick to prevent the deployment from failing when the shared_dir already exists.

Not bad for a day’s work. I tried to include many googleable errors and solutions. I hope it helps.