ABONAMENTE VIDEO REDACȚIA
RO
EN
NOU
Numărul 150
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 79
Abonament PDF

Automatizarea proceselor de livrare software De ce avem nevoie de un asemenea program ?

Adrian Cozac
Senior Software Engineer @ Itiviti



PROGRAMARE

Pentru a putea vedea în esență motivarea din spatele creării unui asemenea utilitar, consider că este necesară o introducere în contextul problemei. De obicei, fiecare dintre noi lucrează în cadrul unei echipe mai mici sau mai mari și care dezvoltă sau mențin unul sau mai multe produse/componente care trebuie să fie livrate la un moment dat. Depinzând de companie și de domeniul produselor care trebuie furnizate, procesul de livrare (începând de la cod și până la livrarea produsului final către clienți) poate să fie destul de complex, necesitând timp, pe care un programator sau tester îl poate folosi pentru a face lucruri mult mai creative.

Beneficiile unei asemenea abordări sunt diverse: de la eliminarea posibilității factorului uman de a face erori, până la faptul că se va ajunge la o standardizare a procesului de livrare la nivel de companie.

Studiu de caz:

Acestea fiind spuse, am definit algoritmul de livrare în felul următor: 

Vederea în jenkins va fi următoarea:

Fig.1. Vederea pașilor procesului de livrare, cu jenkins pipeline 

Cum s-a realizat acest tool ?

Tot acest mecanism de automatizare a procesului de livrare s-a realizat cu ajutorul tehnologiei Jenkins Pipeline. Mai exact, această tehnologie este o suită de plug-in-uri care ne permite implementarea unui sistem de Continuous Delivery Pipelines. În fond, tot ceea ce facem, este să scriem o suită de scripturi care orchestrate de un script părinte, va executa pașii algoritmului de livrare. Jenkins ne propune un limbaj specific domeniului, anume Jenkins DSL cu ajutorul căruia putem să ne definim scriptul de orchestrare a etapelor de livrare. 

Concepte pipeline:

Cu ajutorul acestui limbaj, putem să ne definim node-uri care corespund unei mașini capabile să execute scriptul pipeline. În cadrul fiecărui nod, ne definim stage-uri care reprezintă un subset de pași executați în cadrul pipeline-ului, fiecare dintre acești pași pot fi definiți în cardul unei secțiuni steps, ultima secțiune fiind opțională :

node {
  stage ("Remove snapshots") { ...}
  stage ("Verify JIRAs") { ... }
  stage ("Create the build") { ... }
  stage ("Run integration tests") { ... } 
  stage ("Check distribution") { ... }
  stage ("Upload on release center") { ... }
  stage ("Update version and commit after release")
   {...}
}

Fiecare stage poate fi configurat după necesitați. În cazul nostru, fiecare stage are responsabilitatea de a activa un jenkins job, de a procesa răspunsul acestuia și de a decide următoarele acțiuni pe baza răspunsului primit. Aceasta abordare ne dă posibilitatea să ne definim checkpoints per stage. Beneficiul acestor checkpoints este faptul că dă posibilitatea utilizatorului să interacționeze cu pipeline-ul în cazul unor situații excepționale (ex. Probleme de infrastructură sau hardware). În cazul unei intervenții manuale, utilizatorul are opțiunea de a reîncerca un anumit pas. De asemenea, poate ignora acel pas sau poate să oprească tot procesul de livrare. Aceste acțiuni pot varia în funcție de implementare.

Cu toate că avem la dispoziție jenkins pipeline DSL cu ajutorul căruia reușim procesul de definire și de orchestrare a pașilor de livrare, în cazul de față ne-a fost de foarte mare folosință o suită de gradle plugins prin intermediul cărora am implementat diverse taskuri care sunt manevrate în cadrul pipeline-ului, de exemplu: crearea artefactului auto-descriptiv și diverse taskuri de gradle care ne ajută în procesul de livrare. Odată avute aceste utilități și scriptul de pipeline (cu scripturile din interiorul pașilor), putem să livrăm oricare componentă care se pretează standardului propus, cu o minimă configurare: la nivel de componentă, trebuie aplicate acele plug-in-uri despre care menționam mai sus.

Tot procesul anterior se poate realiza fără necesitatea absolută a anumitor plug-in-uri, având suport nativ în Jenkins DSL pentru pașii cel mai des folosiți, cum ar fi: accesarea unui repository SCM, lucrul cu fișiere, git commit, folosirea variabilelor de sistem etc. . 

De asemenea, jenkins pipeline ne permite rularea în paralel a anumitor pași. Această capabilitate este utilă mai ales în cadrul produselor care au mai multe suite de teste de integrare. Toate aceste teste pot fi rulate în paralel, astfel se salvează timp în procesul de livrare.

În cele mai multe cazuri, fiecare dintre produsele noastre au mai multe versiuni și în anumite situații este nevoie să furnizăm același produs în multiple versiuni (per branch). Acest lucru este posibil, folosind multi-branch pipeline, adică ne putem integra utilitarul cu Git, astfel încât fiecare branch poate fi abordat independent în procesul de livrare.

Tot acest proces automat are sens în cazul în care produsul nostru este acoperit de o suită de teste automate (sau mai multe) pentru a fi încrezători în calitatea produsului livrat. Așadar, Jenkins Pipeline vine în ajutorul acestor produse (cu mai multe nivele de testare automată) și dă posibilitatea implementării unor pași care să ruleze în mod paralel. Următorul pas este rulat doar dacă toți pașii anteriori (rulați în paralel) au fost executați.

Rularea în paralel a anumitor pași poate fi realizată prin simpla plasare a acestora în cadrul unei directive paralele.

 Fig. 2. Structura pipeline în mod paralel- exemplu

Odată pus la punct un asemenea utilitar și odată deținută infrastructura necesară, se poate preda orice produs care se pretează procesului definit. Din moment ce procesul de livrare este unul destul de complex, iar rezultatul coincide cu livrarea către client a unei componente software, un pas foarte important este modalitatea de testare a procesului în sine, în speță a utilitarului. Acest lucru se poate utiliza valorificând frameworkul de testare JenkinsPipelineUnit, cu ajutorul căruia putem scrie unit teste care să ne valideze configurarea și logica condițională din codul pipeline. În acest fel, avem posibilitatea să facem mock la execuția efectivă a pipeline-ului (cum ar fi comenzi și configurări de jenkins).

Considerații finale

Tehnologia Jenkins Pipeline este în fond, un utilitar de automatizare continuă a anumitor procese software, extensibile prin design, folosind multitudinea de plug-in-uri puse la dispoziție de comunitatea jenkins. Prin urmare, în multe situații se dovedește a fi o bună alegere, sau cel puțin o posibilitate care trebuie luată în considerare, atunci când vrem să automatizăm anumite procese în cadrul echipe/companiei noastre. Această extensibilitate este extrem de utilă, deoarece oricine își poate crea propriul gradle plug-in care poate fi folosit în cadrul pipeline-ului.  Cu alte cuvinte, poate fi ușor integrat cu orice utilitar privat sau open-source

Pe lângă toată această abilitate de integrare, avem beneficiul de a descrie procesul de livrare prin intermediul codului, folosind Jenkins DSL și implicit Groovy DSL. De asemenea, vom avea și un istoric de versionare, astfel încât orice modificare în procesul de livrare va putea fi verificată și trecută prin procesul de review al companiei. 

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