Hudson Continuous Integration testing met Rails 3 en RVM

Gepubliceerd op 21 oktober 2011 door Martijn

In de Rails wereld zijn het gebruik van versiebeheer en het schrijven van tests of specs gemeengoed. Een Continuous Integration server is een nuttige toevoeging aan je bestaande ontwikkelproces. Deze server houdt het centrale repository in de gaten en zodra er een wijzing is voert de CI server de specs uit. Indien de specs falen wordt er een mail gestuurd aan de aangewezen beheerder en eventueel aan degene die de verantwoordelijke commit heeft gemaakt. In deze post geven we kort een up-to-date uitleg over het configureren van de Hudson CI server voor Ruby on Rails.

Hudson is een volwassen CI server die zijn oorsprong vindt in de Java wereld. Er zijn ook Ruby-specifieke CI servers, maar Hudson kwam op ons over als de meest volwassen oplossing. Bovendien heeft het standaard support voor Ruby, Rails en Git, dus het sluit perfect aan bij onze werkwijze. Bovendien is Hudson zeer eenvoudig te installeren. Op de Hudson wiki staan installatieinstructies voor verschillende besuringssystemen: Installing Hudson.

Op onze CentOS server was de installatie zo gepiept met de officiële RPM:

rpm -ivh http://hudson-ci.org/downloads/redhat/hudson-2.1.2-1.1.noarch.rpm
/sbin/service hudson start

Hudson start dankzij zijn ingebouwde servlet container op poort 8080 en is na enkele minuten klaar voor gebruik. Elk project is in Hudson een losse job. Laten we gelijk een job aanmaken voor ons ‘Depot’ project:

Een Free-style project biedt volledige vrijheid in de configuratie van het build proces. Na het aamaken komen we direct in de configuratie terecht. De eerste stap, de configuratie van SCM, wijst zichtzelf:

Onder ‘Build triggers’ stellen we in dat Hudson elke 5 minuten ons repository nazoekt op wijzigingen. De interval wordt opgegeven in crontab notatie. Vervolgens voegen we met de ‘Add build step’ een ‘Execute shell’ stap toe:

Dit geeft ons een textvak waarin we ons build proces kunnen specificeren. Het onderstaande script is geschikt voor een Rails 3 applicatie op een server met een systeem-brede RVM installatie:

#!/bin/bash -

# Laad RVM
source "/usr/local/rvm/scripts/rvm"

# Gebruik de juiste Ruby versie
rvm use 1.9.2

# Installeer de gems uit de Gemfile
bundle install --deployment

# Maak een database.yml aan
echo "development:
  adapter: mysql2
  encoding: utf8
  database: hudson_depot_dev
  username: hudson_depot_dev
  password: ...
  pool: 5
  timeout: 5000
test:
  adapter: mysql2
  encoding: utf8
  database: hudson_depot_test
  username: hudson_depot_test
  password: ...
  pool: 5
  timeout: 5000" > config/database.yml

# Laad het database schema
bundle exec rake db:schema:load --trace

# Voer de specs uit, met rcov
bundle exec rake spec:rcov --trace

Er zullen ongetwijfeld aanpassingen nodig zijn voor je eigen applicatie, maar met dit voorbeeld zou je uit de voeten moeten kunnen. Voordat we op de Build now knop kunnen duwen moeten we Hudson nog toegang geven tot het repository door een SSH key aan te maken en deze op de juiste plaats in de homedir van de hudson gebruiker te plaatsen. Mogelijk moet je bij de Hudson instellingen (_Manage Hudson_) nog even de juiste locatie van de git binary op je systeem aangeven. Daarna kun je met Build now de eerste build uitvoeren. Via de console log kun je exact zien wat er gebeurt.

Meer stappen zijn er niet nodig om je Rails applicatie automatisch te testen. Uiteraard is het niet de bedoeling dat er code gecommit wordt die tot falende specs leidt maar de praktijk leert dat het toch wel eens voorkomt. CI testing is een extra stok achter de deur die ervoor zorgt dat problemen snel opgemerkt en opgelost worden. Het hoofdscherm geeft een mooi overzicht van de status van de verschillende projecten:

De weersverwachtingen geven de staat van het project aan. Een zonnetje betekent dat alle recente ‘builds’ succesvol waren. Wolken, regen of onweer geven aan dat het minder goed gaat. De status van de laatste build zie je aan de gekleurde bol vooraan de regel. Blauw = gezonde build, Geel = build met problemen, Rood = mislukte build. Met de Console knop kun je de output van de laatste build bekijken en met de ‘Schedule build’ knop kun je direct een nieuwe build starten.

Het sturen van een e-mail bij problemen is natuurlijk leuk, maar dankzij de flexibiliteit van Hudson kunnen er ook direct maatregelen genomen worden, zoals we in deze blog post van Papercut zien:

Reacties