ABONAMENTE VIDEO REDACȚIA
RO
EN
NOU
Numărul 149
Numărul 148 Numărul 147 Numărul 146 Numărul 145 Numărul 144 Numărul 143 Numărul 142 Numărul 141 Numărul 140 Numărul 139 Numărul 138 Numărul 137 Numărul 136 Numărul 135 Numărul 134 Numărul 133 Numărul 132 Numărul 131 Numărul 130 Numărul 129 Numărul 128 Numărul 127 Numărul 126 Numărul 125 Numărul 124 Numărul 123 Numărul 122 Numărul 121 Numărul 120 Numărul 119 Numărul 118 Numărul 117 Numărul 116 Numărul 115 Numărul 114 Numărul 113 Numărul 112 Numărul 111 Numărul 110 Numărul 109 Numărul 108 Numărul 107 Numărul 106 Numărul 105 Numărul 104 Numărul 103 Numărul 102 Numărul 101 Numărul 100 Numărul 99 Numărul 98 Numărul 97 Numărul 96 Numărul 95 Numărul 94 Numărul 93 Numărul 92 Numărul 91 Numărul 90 Numărul 89 Numărul 88 Numărul 87 Numărul 86 Numărul 85 Numărul 84 Numărul 83 Numărul 82 Numărul 81 Numărul 80 Numărul 79 Numărul 78 Numărul 77 Numărul 76 Numărul 75 Numărul 74 Numărul 73 Numărul 72 Numărul 71 Numărul 70 Numărul 69 Numărul 68 Numărul 67 Numărul 66 Numărul 65 Numărul 64 Numărul 63 Numărul 62 Numărul 61 Numărul 60 Numărul 59 Numărul 58 Numărul 57 Numărul 56 Numărul 55 Numărul 54 Numărul 53 Numărul 52 Numărul 51 Numărul 50 Numărul 49 Numărul 48 Numărul 47 Numărul 46 Numărul 45 Numărul 44 Numărul 43 Numărul 42 Numărul 41 Numărul 40 Numărul 39 Numărul 38 Numărul 37 Numărul 36 Numărul 35 Numărul 34 Numărul 33 Numărul 32 Numărul 31 Numărul 30 Numărul 29 Numărul 28 Numărul 27 Numărul 26 Numărul 25 Numărul 24 Numărul 23 Numărul 22 Numărul 21 Numărul 20 Numărul 19 Numărul 18 Numărul 17 Numărul 16 Numărul 15 Numărul 14 Numărul 13 Numărul 12 Numărul 11 Numărul 10 Numărul 9 Numărul 8 Numărul 7 Numărul 6 Numărul 5 Numărul 4 Numărul 3 Numărul 2 Numărul 1
×
▼ LISTĂ EDIȚII ▼
Numărul 76
Abonament PDF

Dezvoltarea pluginurilor de Jenkins pentru optimizarea procesului de CI/CD

Andras Petres
DevOps Engineer @ Itiviti



PROGRAMARE


Inspirându-se din mișcarea DevOps, multe companii au aplicat cu succes principiile ei, creând story-uri de succes precum Flickr. Aceste povești de succes ne-au învățat o lecție importantă: integrarea practicilor DevOps-ului precum și automatizarea, continuous integration și continuous delivery au drept efect un nivel de productivitate mai ridicat și release-uri făcute mult mai des.

DevOps și Jenkins

Noi la Itiviti punem un accent deosebit pe continuous integration demolând astfel separarea dintreDev și Ops. Fiecare programator este încurajat să contribuie la sistemul nostru de CI/CD și să automatizeze cât mai multe procese. Pentru că acest sistem este în mare parte automatizat și menținut de comunitatea dezvoltatorilor, sarcina Ops-ului se simplifică.

Backbone-ul acestui sistem este Jenkins, cel mai popular build server de tip open-source, care este responsabil de pipeline-ul de CI/CD: rularea testelor unitare și a celor de integrare, crearea arhivelor de release și lansarea (deploying) produsului într-un mediu de staging. Popularitatea este dată de faptul că Jenkins este foarte ușor de customizat. Există mai mult de 1100 de pluginuri de Jenkins, ca și cel care permite executarea buildurilor bazate pe Gradle sau pe rularea joburilor pe AWS folosind un executor care există doar pe durata buildului. Folosind aceste pluginuri, putem să personalizăm Jenkins în funcție de nevoile organizației noastre, optimizând astfel procesul de CI. De fiecare dată când avem nevoie de vreo funcționalitate personalizată de Jenkins, ne uităm la lista pluginurilor și încercăm să găsim una care oferă soluția dorită. Dar ce se întâmplă când niciun plugin existent nu oferă funcționalitatea de care avem nevoie?

Cazuri de utilizare

Un exemplu de caz de utilizare este prioritizarea buildurilor pe bază de parametri. Putem să ne întâlnim cu situații în care executorii Jenkins sunt foarte ocupați, multe builduri stau la coadă, iar echipa noastră vrea să facă release și vrea să ruleze niște teste de integrare care înainte erau identificate de un parametru de build numit RELEASE. În caz normal testele respective ar trebui să stea la coadă până când celelalte builduri sunt executate, pentru că Jenkins are ca default un scheduler de tip FIFO. Bineînțeles că nu vrem să așteptăm după ele pentru că nu vrem să riscăm amânarea release-ului și nici nu vrem să livrăm produsul fără rezultatele testelor de integrare. Testele noastre ar trebui să fie primele în coada Jenkinsului. Pluginul cel mai asemănător este Build Queue Prioritizer dar, pentru că nu suportă prioritizare după parametri, nu poate fi utilizat pentru atingerea scopului nostru. Rămâne soluția de dezvoltare a pluginului de către noi.

Primul pas în dezvoltarea pluginului propriu este crearea proiectului. Majoritatea pluginurilor este bazată pe Maven (există și un archetype specific pentru pluginurile de Jenkins pentru a ușura generarea structurii proiectului), iar altele sunt bazate pe Gradle. Indiferent de sistemul de build folosit, rezultatul procesului de build este un fișier cu extensie hpi, o arhivă care conține clasele noastre compilate și metadata. Această arhivă este încărcată de Jenkins ori prin upload-are manuală ori prin copierea ei în folderul de JENKINS_HOME/plugins. Jenkins suporta hot deployment dar nu și hot swapping, adică un plugin care este deja încărcat poate fi înlocuit doar cu repornirea Jenkinsului, prelungind astfel timpul de deployment.

"Puterea" secretă a pluginurilor de Jenkins provine din faptul că ele (fiind rulate în același JVM) pot să referențieze obiectele specifice de Jenkins. Jenkins oferă un API bogat și simplu către pluginuri pentru manipularea joburilor, viewurilor, node-urilor și a setărilor. Elementul central al acestui API este clasa jenkins.model.Jenkins. Ca să avem o idee despre cum arată această manipulare, putem să folosim Script Console pentru rularea scripturilor de Jenkins. Această consolă suportă scripturi Groovy (și implicit Java). Fig. 1 exemplifică desemnarea unui node la un job printr-un script de Groovy. Această consolă este foarte utilă pentru a testa codul nostru fără să facem deploy la pluginul dezvoltat de noi, însă nu are suport de auto-completare, este recomandată foloirea ei împreună cu un IDE.

Figura 1. Desemnarea unui node la un anumit job folosind Script Console

Elementul pe care pluginurile îl au în plus în comparație cu scripturile este punctul în care codul este executat. Locurile unde un plugin poate să contribuie la funcționalitatea Jenkins-ului sunt numite puncte de extensie (extension points) și există foarte multe dintre ele, nu numai în Jenkins core ci și în alte pluginuri. Folosind punctele de extensie putem să definim un build step personalizat, putem să adăugăm butoane personalizate la meniul sau putem să ascultăm la sfârșitul buildurilor și să executăm cod personalizat (ex. identificarea problemelor cunoscute din build log). Punctele de extensie sunt interfețe sau clase abstracte care pot fi implementate de pluginuri. Un exemplu este clasa Builder care definește un pas de build care este implementată de gradle-plugin pentru a defini pasul care builduiește proiecte de Gradle. Clase de extensii sunt marcate de adnotarea Extension.

Pentru a implementa pluginul personalizat de sortare folosim punctul de extensie QueueSorter, el fiind o clasă abstractă. Prin implementarea metodei sortBuildableItems putem să definim logica noastră personalizată de sortare, folosind cod de Java/Groovy asemănător cu cel folosit în Script Console. Și suntem gata! Executarea goalului (Maven) / taskului (Gradle) hpi rezultă în generarea fișierului de hpi pe care putem să-l instalăm pe Jenkins.

Pe când cazul de utilizare de mai sus este unul simplu, putem să beneficiem din pluginuri de Jenkins și în cazuri mai complicate. De exemplu, putem să identificăm automat buildurile care au eșuat din motivele cunoscute, să facem acțiuni corective și să retriggeruim buildul. Avantajul acestui caz de utilizare este reducerea interacțiunii umane repetitive cu Jenkins. Cu cât mai mare este numărul buildurilor executate într-o anumită perioadă de timp, cu atât mai mult timp putem să economisim prin acest plugin.

Pluginurile de Jenkins pot depinde de alte pluginuri, exact cum o librărie depinde de cealaltă. Ele sunt declarate în fișierul de build (pom.xml sau build.gradle) ca dependențe comune. În cazul nostru, putem să beneficiem din pluginul de Build Failure Cause care identifică cauza eșuării, folosind o listă de expresii regulare de build log, fiecare corespunzând unei cauze de eșuare. Pluginul de Rebuild ne ajută la re-lansarea buildului, iar cu ajutorul pluginului de Slack putem să trimitem notificări Slack despre acțiunile corective executate, folosind setările de Slack din Jenkins. Ca punct de extensie folosim clasa abstractă RunListener care are (între mai multe) metoda onCompleted, care este apelată la terminarea unui build. În această metodă putem să implementăm logica noastră personalizată care execută acțiunea corectivă, re-lansează buildul folosind pluginul Rebuild și trimite notificare pe Slack despre acțiunile efectuate.

Anumite puncte de extensii suportă extinderea interfeței de utilizator. Cazul de utilizare este adăugarea unui buton la fiecare nod care îl repornește, scopul fiind "curățarea" lui. Implementarea repornirii depinde de tipul nodului folosit și poate să fie un restart simplu sau recrearea containerului de gazdă, pentru a asigura un mediu stabil și curat. Punctul de extensie folosit este TransientButtonActionFactory, prin extinderea acestei clase putem să filtrăm nodurile pentru care se afișează butonul și să specificăm acțiunea care este executată la evenimentul de click. Această acțiune este definită într-o clasă care implementează interfața Action, o interfață folosită pentru multe feluri de acțiune în Jenkins, conform șablonului de proiectare strategy. Dar noi nu vrem doar să adăugăm un buton, ci să creăm și o pagină nouă de confirmare. Pluginurile de Jenkins ne permit să extindem UI-ul folosind Apache Jelly, o tehnologie bazată pe XML care este asemănătoare de JSP. Creând fișierul de index.jelly în folderul de resurse, folosind același package ca și clasa de Action creat pentru node, îl afișează pagina, când utilizatorul face click de buton de restart. Ca și în cazul paginilor de JSP, pe paginile de Jelly putem să definim formuri de HTML și să definim acțiunea de submit, care de fapt este un apel de metodă din clasa de Action. În această metodă implementăm logica de restart, eventual redirecționăm utilizatorul către pagina principală a Jenkins.

Concluzii

În cazurile de utilizare menționate am demonstrat cum putem să automatizăm câteva sarcini legate de CI folosind pluginuri de Jenkins. Pe lângă funcționalitățile menționate, pluginurile oferă și alte funcționalități precum și internaționalizare, restricții bazate pe permisiile utilizatorului, puncte de extensie custom, etc. Sperăm că exemplele furnizate evidențiază avantajele dezvoltării pluginurilor proprii de Jenkins și în același timp încurajează cititorul să contribuie la sistemul de CI/CD al organizației sale.

LANSAREA NUMĂRULUI 150

Noile tehnologii SAP ABAP

Marți, 10 Decembrie, ora 18:00

sediul MHP - A Porsche Company

Facebook Meetup StreamEvent YouTube

NUMĂRUL 149 - Development with AI

Sponsori

  • Accenture
  • BT Code Crafters
  • Accesa
  • Bosch
  • Betfair
  • MHP
  • BoatyardX
  • .msg systems
  • P3 group
  • Ing Hubs
  • Cognizant Softvision
  • Colors in projects