După Martin Fowler: Integrarea Continuă (Continuous Integration) este o practică unde membrii echipei își integrează schimbările frecvent în proiect cel puțin odată pe zi. Fiecare schimbare este verificată de un build automat care compilează codul, rulează teste, verifică stilul codului scris, etc și detectează erorile cît de repede posibil. Multe echipe au găsit această practică foarte binevenită, care elimină multe probleme de integrare dintre echipe.

Această practică permite de a menține o calitate a codului destul de înaltă, micșorând drastic pierderile de timp la integrarea componentelor.

Fiindcă rails/ruby nu are stadie de compilare, rămâne doar de verificat testele și migrărea bazei de date. Aveam o idee să integrez un script de IC pentru site-ul www.assembla.com și astăzi am muncit la un așa script.

Deci un script de IC pentru rails trebuie să execute următorii pași:

  • Să actualizeze codul sursă din repositoriul central

  • Dacă sunt schimbări în repositoriu, să verifice build-ul

Verificarea build-ului constă în:

  • ștergerea bazei de date pentru development

  • rularea migrărilor - verifică ca să nu fie probleme pentru membrii noi de echipă, care își instalează proiectul de la zero.

  • rularea testelor - verifică dacă ultimele schimbări din repositoriu nu a stricat careva teste, în caz că developerul a uitat să le ruleze înainte de a face commit.

Rezultatul muncii de astăzi l-am pus pe github sub denumirea de cia_rails

http://github.com/vitaliel/cia_rails/tree/master

La moment lucrează numai cu git, dar ușor poate fi adaptat să lucreze cu subversion, mercurial și alte sisteme de control al versiunilor. Este inteligent să nu trimită email la fiece build stricat. Email se trimite la persoana QA, dar pe viitor plănuiesc să trimată înștiințare pe email numai la developerii care au adăugat schimbări in repositoriu, adică cineva din ei e vinovat de stricarea build-ului.

Mai am ceva idei cum se poate de îmbunătățit:

  • email-ul trimis sa conțină linkul la changeset-ul cu schimbarea facută.

  • email-ul să conțină fișierele modificate, ca să fie mai ușor de identificat vinovatul.

  • de creat o extensie build tool pentru www.assembla.com unde scriptul va posta evenimente despre build, cynd a fost stricat/reparat.

Referințe