TODAY SOFTWARE MAGAZINE (master) poate rula pe o mașină Linux, în timp ce sclavii pot rula pe diferite platforme (Windows, MacOS X - orice care poate rula Java), făcând posibil rularea procesului de build pe toate platformele suportate • Stabiliți limite pentru procesul de build. Specificați timpul maxim care poate să dureze pentru a preveni un build blocat care să consume toate resursele. Specificați numărul maxim de build-uri vechi pe care ar trebui să fie arhivate pentru a evita umplerea spațiului pe disc. • Profitați de job-urile parametrizate pentru a evita crearea job-urilor (aproape) identice. • Profitați de declanșarea de la distanță (remote triggering) a job-ului. În acest fel un build poate fi declanșat chiar în momentul în care o anumită schimbare a fost comisă să vă informați despre hooks / webhooks pentru VCS-ul vostru. • Rupeți build-ul în pași mai mici - de exemplu, un pas ar putea fi rularea unit test-elor, a doua ar fi rularea testelor de integrare și un al treilea pas ar putea să fie rularea analizei statice. Pașii mici oferă feedback mai rapid și fac posibilă rularea mai multor pași în paralel. • Când rupeți un proces în pași mici, asigurați-vă că fiecare pas operează pe exact aceleași fișiere sursă. Fiți cât mai specifici. Specificarea unui branch nu este suficient de specific, folosiți identificatorii de commit / changeset. • Jenkins te poate notifica în mai multe moduri cu privire la progresele job-ului (build-ul a început / a reusit / a eșuat) - în interfața web, e-mail, chat. Să-l configurați în așa fel încât să fie cât mai convenabil pentru membrii echipei dar să nu le spameze. Alte variante în afară de Jenkins ar fi: TeamCity, CruiseControl și Travis-CI. Cea de-a doua parte a unui astfel de configurări este un loc pentru a ține codul și comentariile legate de revizii. Acest lucru poate fi un sistem sau două sisteme distincte (în cazul în acesta aveți nevoie să le sincronizați - probabil folosind Jenkins). Câteva variante: • soluții complete (cod hosting și revizuire): Github, BitBucket, Google Code, hosted TFS • Cod hosting pe care le puteți instala pe serverul vostru: RhodeCode, Gitorious, Gitlab, gitweb, hgserv • R e v i z u i r e d e c o d : G e r r i t , ReviewBoard, Rietveld
A treia piesă a puzzle-ului este un sistem care efectuează analiza statică pe cod pentru a oferi feedback despre problemele care pot fi detectate în mod automat. Pentru aceasta recomand SonarQube 5 (cunoscut anterior sub numele Sonar). Ea nu face analiză statică pe cont propriu, ci consumă rapoartele create de alte instrumente (cum ar fi FindBugs, FxCop, Pylint, etc) și le prezintă într-o interfață web frumoasă, oferind o clasificare a problemelor, statistici, rapoarte cu schimbări și așa mai departe. Câteva sfaturi legate de folosirea SonarQube: • are o arhitectură ciudată: analiza se execută pe client care are nevoie de acces direct atât la interfața web cât și la baza de date. • analiza unui proiect mare poate să dureze o lungă perioadă de timp și să consume multe resurse (CPU/ memorie - puteți găsi sfaturi specifice pentru proiecte mari de Java pe blog-ul Transylvania JUG6). Dacă apar astfel de probleme, este un indicator bun că ar trebui să despărțiți proiectul în mai multe module mici. • SonarQube are nevoie de o bază de date performantă. Nu rulați cu baza de date încorporată (H2) cu care vine sau cu o instanță MySQL slabă. Recomand să folosiți un PostgreSQL configurat corect.
și David Farley. De asemenea, puteți arunca o privire asupra unei prezentări cu acest subiect8 sau puteți să mă contactați pentru întrebări / sfaturi sau chiar să veniți la următoarea întâlnire Cluj.PM9 unde voi vorbi despre acest subiect.
Concluzii
Existența unui ”deployment pipeline” are multe beneficii. Se eliberează timpul pe echipe. Instalarea se face mai repede și garantează rezultate consistente. Asigură că procesul de instalare este definit cu precizie (suficient de precis ca să-l poate executa un calculator). De asemenea, ne învață despre instrumentele de bază și despre linia de comandă, un lucru indispensabil pentru a depana problemele de producție. Puteți aplica livrarea continuă la toate tipurile de sisteme software, nu doar siteuri sau servicii găzduite (acolo unde este cel mai ușor). Pipeline-ul poate produce installkit-uri sau chiar mașini virtuale complete cu software-ul preinstalat. Livrarea continuă nu înseamnă neapărat că trebuie livrat noul software-ul la client de fiecare dată când se schimbă ceva. Înseamnă doar că aveți opțiunea de a face acest lucru la orice moment în timp. O carte bună (deși ușor depășită) este ”Continuous Delivery : Reliable Software Releases through Build, Test, and Deployment Automation7” de Jez Humble 5 6 7
http://www.sonarqube.org/ http://www.transylvania-jug.org/archives/5702 ISBN: 978-0321601919
8 http://vunvulearadu.blogspot.ro/2013/09/postevent-web-codecamp-event-in-cluj.html 9 http://cluj.pm/
www.todaysoftmag.ro | nr. 16/Octombrie, 2013
41