Tag Archive for 'Ruby (on Rails)'

Deploying to Heroku from TeamCity

Previously I discussed our TeamCity configuration using RVM and mentioned that we often use git to deploy projects. Today I’ll share an example of how a TeamCity build agent can trigger deployments of a application hosted on Heroku and some of the challenges I found.
Continue reading ‘Deploying to Heroku from TeamCity’

Using RVM on TeamCity build agents

We have been using TeamCity to manage the continuous integration, testing, and deployment of many of our recent projects. We have also been using RVM on all of our recent Rails projects to allow us to install multiple ruby versions and create isolated gemsets for each project. RVM proved to be particularly useful on our TeamCity build agents where it allows a single agent to build many projects without the fear that we will see gem or ruby version conflicts between projects or introduce dependencies on gems installed on the build server but not enumerated in the project. Here’s the configuration I have used to get our build agents to use each project’s RVM settings.
Continue reading ‘Using RVM on TeamCity build agents’

How to install rails on CentOS 5.4 x64

1. Download ruby source

wget http://ftp.ruby-lang.org/pub/ruby/1.8/ruby-1.8.7.tar.gz
tar -zxvf ruby-1.8.7.tar.gz

2. Install dependencies

sudo yum install gcc
sudo yum install gcc-c++
sudo yum install zlib-devel
sudo yum install openssl-devel
sudo yum install readline-devel
sudo yum install sqlite3-devel

3. Build ruby from source

cd ruby-1.8.7
./configure --with-openssl-dir=/usr/lib64/openssl
make
sudo make install

4. Download rubygems source

wget http://rubyforge.org/frs/download.php/69365/rubygems-1.3.6.tgz
tar -zxvf rubygems-1.3.6.tgz
cd rubygems-1.3.6
sudo ruby setup.rb

5. Install gems

sudo gem install rake
sudo gem install rails
sudo gem install sqlite3-ruby (optional)

Automatically deploying to Engine Yard Cloud

I’m working on a application which is deployed to Engine Yard’s Cloud infrastructure and I wanted to automatically redeploy the application whenever our tests passed on our continuous integration server.

Engine Yard will eventually allow us to push a branch to our cloud environment from git (ie “git push engineyard master”) but until that is available the best option seems to be to trigger a github post receive hook directly.

To that end I rewrote an existing script to trigger post receive hooks as a rake task; http://gist.github.com/271433
Continue reading ‘Automatically deploying to Engine Yard Cloud’

assert_changes and assert_no_changes in Ruby

Update: This code and documentation is now available on github: http://github.com/ndp/assert_changes/tree/master

The Problem

On our work on gobalto.com, we spend time to have good fixture data for our tests– data that can represent all the important application states that our tests require. As a result, our tests are very dependent on the data. It’s important that someone doesn’t inadvertantly change it in subtle ways. This has led us to write not only asserts at the end of tests, but pre-conditions as well. For example,

    ...
    inotech = companies(:inotech)
    assert inotech.services.public.include?(categories(:a))
    assert inotech.services.public.include?(categories(:b))
    assert inotech.services.public.include?(categories(:c))
 
    post :edit_services_dialog, :id=>inotech.id,
                                          :service_category_id=>categories(:a).id
    inotech.reload
 
    assert inotech.services.public.include?(categories(:a))
    assert !inotech.services.public.include?(categories(:b))
    assert !inotech.services.public.include?(categories(:c))

Although the pre-conditions were introduced to guard against accidentally changing fixture data (or just to figure out what’s going on), we don’t necessarily delete them. They provide stronger tests. And in some ways, leaving in pre-conditions make the code more readable by providing documentation of your assumptions to the readers. The code above would be hard to follow without the clarifying pre-conditions. What do we expect to change and what stays the same?

Unfortunately all these asserts make the tests twice as long. And there’s a subtle readability problem: there’s no relationship between the corresponding pre- and post-conditions. In the example above, you have to scan carefully to see that the three assertions are repeated, but negated (b and c only). The reader must mentally put pieces together. And it’s not DRY. Using local variables doesn’t help much.

The Solution

I was inspired by a nice little test helper called assert_difference. It takes a string to evaluate and a block to execute. It’s useful for checking on state changes– especially database changes– during a test:

assert_difference('Company.count', -1) do
    Company.delete_one
end

(Without this method, we rely on a count of all database records, or merely look for specific ones. The former approach leads to brittle tests, and the latter to incomplete assertions.)

A limitation of assert_difference is that it only deals with integers. What if it were generalized? Here goes:

    i = true
    assert_changes 'i' => false do   # read as: i changes to false
      i = false
    end

Continue reading ‘assert_changes and assert_no_changes in Ruby’

Convenient CSS and Javascript in Ruby on Rails

I get tired of hunting through a hierarchy of folders and files, from the views to the public folder, to locate a certain CSS or Javascript file. It’d be convenient to have them right with the markup, but embedding these definitions within your HTML markup is a bad idea for several reasons. For our current project, I proposed we put everything in the view directory so they are easy to find:

app/
  views/
    home/
      index.html.rb
      index.css
      index.js

The convention is clear: to add page-specific CSS code, just create a new file with the same name as the view, in the same folder. Easy to add, edit and remove. The alternative (using the public folder), usually leads to a parallel hierarchy and the inconvenience of that.

I also thought, that this being Rails and all, the files should be included automatically. It turned out to be pretty easy. Continue reading ‘Convenient CSS and Javascript in Ruby on Rails’