Tutorial de livrare continuă - Construirea unei conducte de livrare continuă folosind Jenkins

Livrare continua:

Livrarea continuă este un proces în care modificările de cod sunt construite, testate și pregătite automat pentru lansarea în producție.Sper că ți-a plăcut Aici, voi vorbi despre următoarele subiecte:

• Ce este livrarea continuă?
• Tipuri de testare software
• Diferența dintre integrare continuă, livrare și implementare
• Care este nevoia de livrare continuă?
• Practic folosind Jenkins și Tomcat

Să înțelegem rapid cum funcționează livrarea continuă.

Ce este livrarea continuă?

Este un proces în care construiți software în așa fel încât să poată fi lansat în producție în orice moment.Luați în considerare diagrama de mai jos:

cum se creează un șir aleatoriu în java

Permiteți-mi să explic diagrama de mai sus:

• Scripturile automate de construire vor detecta modificări în gestionarea codului sursă (SCM), cum ar fi Git.
• Odată ce modificarea este detectată, codul sursă va fi implementat pe un server de construire dedicat pentru a vă asigura că construirea nu eșuează și că toate clasele de testare și testele de integrare rulează bine.
• Apoi, aplicația de compilare este implementată pe serverele de testare (servere de pre-producție) pentru Testul de acceptare a utilizatorului (UAT).
• În cele din urmă, aplicația este implementată manual pe serverele de producție pentru lansare.

Înainte de a continua, va fi corect să vă explic diferitele tipuri de testare.

Tipuri de testare software:

În linii mari, există două tipuri de testare:

• Testare cutie neagră: Este o tehnică de testare care ignoră mecanismul intern al sistemului și se concentrează pe ieșirea generată împotriva oricărei intrări și execuții a sistemului. Se mai numește testare funcțională. Este utilizat în principiu pentru validarea software-ului.
• Testarea cutiei albe: este o tehnică de testare care ia în considerare mecanismul intern al unui sistem. Se mai numește testarea structurală și testarea cutiei de sticlă. Este utilizat în principiu pentru verificarea software-ului.

Testarea cutiei albe:

Există două tipuri de teste care se încadrează în această categorie.

• Testarea unitara: Este testarea unei unități individuale sau a unui grup de unități conexe. Programatorul face adesea testarea faptului că unitatea pe care a implementat-o ​​produce o ieșire așteptată în raport cu intrarea dată.
• Testarea integrării: Este un tip de testare în care se află un grup de componentecombinate pentru a produce ieșirea. De asemenea, interacțiunea dintre software și hardware este testată dacă componentele software și hardware au vreo relație. Poate intra atât în ​​testarea cutiei albe, cât și în testarea cutiei negre.

Testare cutie neagră:

Există mai multe teste care se încadrează în această categorie. Mă voi concentra asupracâțiva, care sunt importante pentru dvs. să știți, pentru a înțelege acest blog:

• Testarea funcțională / de acceptare: Se asigură că funcționalitatea specificată necesară în cerințele sistemului funcționează. Se face pentru a vă asigura că produsul livrat îndeplinește cerințele și funcționează conform așteptărilor clientului
• Testarea sistemului: Se asigură că punând software-ul în medii diferite (de exemplu, sisteme de operare) funcționează în continuare.
• Testare stresanta: Evaluează modul în care sistemul se comportă în condiții nefavorabile.
• Testarea beta: Acesta este realizat de utilizatorii finali, de o echipă în afara dezvoltării sau care lansează public versiunea completă a produsului, denumităbetaversiune. Scopul testării beta este de a acoperi erorile neașteptate.

Acum este momentul corect pentru mine să explic diferența dintre integrare continuă, livrare și implementare.

Diferențe între integrare continuă, livrare și implementare:

Conținutul vizual ajunge la creierul unei persoane într-un mod mai rapid și mai ușor de înțeles decât informațiile textuale. Deci, voi începe cu o diagramă care explică clar diferența:

În Integrare continuă, fiecare validare de cod este construită și testată, dar nu este în stare să fie lansată. Adică aplicația de compilare nu este implementată automat pe serverele de testare pentru a o valida folosind diferite tipuri de testare Blackbox, cum ar fi - Testarea acceptării utilizatorului (UAT).

În livrare continuă, aplicația este implementată continuu pe serverele de testare pentru UAT. Sau, puteți spune că aplicația este gata să fie lansată în producție oricând. Deci, evident, integrarea continuă este necesară pentru livrarea continuă.

Implementarea continuă este următorul pas după livrarea continuă, în care nu creați doar un pachet implementabil, ci îl implementați într-un mod automat.

Permiteți-mi să rezum diferențele folosind un tabel:

În termeni simpli, Integrarea continuă este o parte atât a livrării continue, cât și a implementării continue. Și implementarea continuă este ca livrarea continuă, cu excepția faptului că lansările au loc automat.

Aflați cum să creați conducte CI / CD folosind Jenkins On Cloud

Dar întrebarea este dacă integrarea continuă este suficientă.

De ce avem nevoie de livrare continuă?

Să înțelegem acest lucru cu un exemplu.

Imaginați-vă că există 80 de dezvoltatori care lucrează la un proiect mare. Folosesc conducte de integrare continuă pentru a facilita construcțiile automatizate. Știm că construirea include și testarea unitară. Într-o zi, au decis să implementeze cea mai recentă versiune care a trecut testele unitare într-un mediu de testare.

Aceasta trebuie să fie o abordare lungă, dar controlată a desfășurării pe care specialiștii lor în mediu au realizat-o. Cu toate acestea, sistemul nu părea să funcționeze.

Care ar putea fi cauza evidentă a eșecului?

Ei bine, primul motiv pentru care majoritatea oamenilor se vor gândi este că există o anumită problemă cu configurația. Ca majoritatea oamenilor, chiar și ei credeau asta.Au petrecut mult timp încercând să găsească ceea ce nu era în configurația mediului, dar nu au putut găsi problema.

Un dezvoltator perceptiv a luat o abordare inteligentă:

Apoi, unul dintre dezvoltatorii principali a încercat aplicația pe mașina sa de dezvoltare. Nici acolo nu a funcționat.

El a făcut un pas înapoi prin versiunile anterioare și anterioare până când a constatat că sistemul a încetat să funcționeze cu trei săptămâni mai devreme. O mică eroare obscură împiedicase pornirea corectă a sistemului. Deși, proiectul a avut o acoperire bună a testelor unitare.În ciuda acestui fapt, 80 de dezvoltatori, care au efectuat de obicei doar testele, mai degrabă decât aplicația în sine, nu au văzut problema timp de trei săptămâni.

Declarație problemă:

Fără a rula teste de acceptare într-un mediu de producție, nu știu nimic despre dacă aplicația îndeplinește specificațiile clientului și nici dacă poate fi implementată și poate supraviețui în lumea reală. Dacă doresc feedback în timp util cu privire la aceste subiecte, trebuie să extindă gama procesului lor de integrare continuă.

Permiteți-mi să rezum lecțiile învățate examinând problemele de mai sus:

• Testele unitare testează doar perspectiva dezvoltatorului cu privire la soluția unei probleme. Au doar o capacitate limitată de a demonstra că aplicația face ceea ce se presupune din perspectiva utilizatorilor. Nu sunt de ajunsidentifică problemele funcționale reale.
• Implementarea aplicației pe mediul de testare este un proces complex, manual intensiv, care a fost destul de predispus la erori.Aceasta a însemnat că fiecare încercare de implementare a fost un experiment nou - un proces manual, predispus la erori.

Soluție - Conductă de livrare continuă (test automat de acceptare):

Au dus la integrarea continuă (livrare continuă) la pasul următor și au introdus câteva teste de acceptare simple și automate care au dovedit că aplicația a rulat și că își poate îndeplini funcția cea mai fundamentală.Majoritatea testelor care se desfășoară în timpul etapei Testului de acceptare sunt teste funcționale de acceptare.

Practic, au construit o conductă de livrare continuă, pentru a se asigura că aplicația este implementată perfect în mediul de producție, asigurându-se că aplicația funcționează bine atunci când este implementată pe serverul de testare, care este o replică a serverului de producție.

Destul de teorie, vă voi arăta acum cum să creați o conductă de livrare continuă folosind Jenkins.

Conductă de livrare continuă folosind Jenkins:

Aici voi folosi Jenkins pentru a crea o conductă de livrare continuă, care va include următoarele sarcini:

Pașii implicați în demonstrație:

• Se preia codul din GitHub
• Compilarea codului sursă
• Testarea unității și generarea rapoartelor de testare JUnit
• Ambalarea aplicației într-un fișier WAR și implementarea acesteia pe serverul Tomcat

Cerințe prealabile:

• Mașină CentOS 7
• Jenkins 2.121.1
• Docher
• Tomcat 7

Pasul 1 Compilarea codului sursă:

Să începem prin a crea mai întâi un proiect Freestyle în Jenkins. Luați în considerare captura de ecran de mai jos:

Dați un nume proiectului dvs. și selectați Freestyle Project:

Când derulați în jos, veți găsi o opțiune pentru a adăuga un depozit de cod sursă, selectați git și adăugați adresa URL a depozitului, în acel depozit există o amendă pom.xml pe care o vom folosi pentru a construi proiectul nostru. Luați în considerare captura de ecran de mai jos:

care este diferența dintre java și c ++

Acum vom adăuga un Build Trigger. Alegeți opțiunea de sondaj SCM, practic, vom configura Jenkins să sondeze depozitul GitHub după fiecare 5 minute pentru modificări ale codului. Luați în considerare captura de ecran de mai jos:

Înainte de a continua, permiteți-mi să vă fac o mică introducere la ciclul de construcție Maven.

Fiecare dintre ciclurile de viață ale construcției este definit de o listă diferită de faze de construcție, în care o fază de construcție reprezintă o etapă din ciclul de viață.

Următoarea listă a fazelor de construire:

• validare - validarea proiectului este corectă și toate informațiile necesare sunt disponibile
• compila - compila codul sursa al proiectului
• test - testați codul sursă compilat utilizând un cadru de testare unitar adecvat. Aceste teste nu ar trebui să necesite ca codul să fie ambalat sau implementat
• package - luați codul compilat și împachetați-l în formatul său distribuibil, cum ar fi un JAR.
• verificați - executați toate verificările rezultatelor testelor de integrare pentru a vă asigura că sunt îndeplinite criteriile de calitate
• instalare - instalați pachetul în depozitul local, pentru utilizare ca dependență în alte proiecte la nivel local
• implementare - realizat în mediul de construire, copiază pachetul final în depozitul la distanță pentru partajare cu alți dezvoltatori și proiecte.

Pot rula comanda de mai jos, pentru compilarea codului sursă, testarea unității și chiar împachetarea aplicației într-un fișier de război:

mvn pachet curat

De asemenea, puteți descompune lucrarea de construire în mai mulți pași de construcție. Acest lucru facilitează organizarea construcțiilor în etape curate și separate.

Deci, vom începe prin compilarea codului sursă. În fila Construire, faceți clic pe invoca ținte de nivel superior și introduceți comanda de mai jos:

compila

Luați în considerare captura de ecran de mai jos:

Acest lucru va extrage codul sursă din depozitul GitHub și îl va compila (Faza de compilare Maven).

Faceți clic pe Salvare și rulați proiectul.

Acum, faceți clic pe ieșirea consolei pentru a vedea rezultatul.

Pasul - 2 teste unitare:

Acum vom crea încă un proiect Freestyle pentru testarea unității.

Adăugați aceeași adresă URL din fila de gestionare a codului sursă, așa cum am făcut în lucrarea anterioară.

Acum, în fila „Buid Trigger” faceți clic pe „build după ce alte proiecte sunt construite”. Acolo introduceți numele proiectului anterior în care compilăm codul sursă și puteți selecta oricare dintre opțiunile de mai jos:

• Declanșați numai dacă versiunea este stabilă
• Declanșați chiar dacă versiunea este instabilă
• Declanșați chiar dacă versiunea eșuează

Cred că opțiunile de mai sus sunt destul de auto-explicative, așa că selectați oricare. Luați în considerare captura de ecran de mai jos:

În fila Construire, faceți clic pe invoca ținte de nivel superior și utilizați comanda de mai jos:

Test

De asemenea, Jenkins vă ajută să vă afișați rezultatele testelor și tendințele rezultatelor testelor.

Standardul de facto pentru raportarea testelor în lumea Java este un format XML utilizat de JUnit. Acest format este utilizat și de multe alte instrumente de testare Java, cum ar fi TestNG, Spock și Easyb. Jenkins înțelege acest format, deci dacă versiunea dvs. produce rezultate ale testului JUnit XML, Jenkins poate genera rapoarte grafice de test și statistici frumoase despre rezultatele testelor în timp și vă permite, de asemenea, să vizualizați detaliile eventualelor eșecuri ale testului. Jenkins ține, de asemenea, evidența duratei de testare, atât la nivel global, cât și pe test - acest lucru poate fi util dacă aveți nevoie să depistați problemele de performanță.

Deci, următorul lucru pe care trebuie să-l facem este să-l facem pe Jenkins să țină seama de testele noastre unitare.

Accesați secțiunea Acțiuni post-construire și bifați caseta de selectare „Publicați raportul rezultatelor testului JUnit”. Când Maven execută teste unitare într-un proiect, acesta generează automat rapoartele de testare XML într-un director numit surefire-reports. Deci, introduceți „** / target / surefire-reports / *. Xml” în câmpul „Testează XML-urile raportului”. Cele două asteriscuri de la începutul căii („**”) sunt o bună practică pentru a face configurația puțin mai robustă: permit Jenkins să găsească directorul țintă, indiferent de modul în care l-am configurat pe Jenkins pentru a verifica codul sursă.

** / target / surefire-reports / *. xml

Salvați-l din nou și faceți clic pe Build Now.

Acum, raportul JUnit este scris în / var / lib / jenkins / workspace / test / gameoflife-core / target / surefire-reports / TEST-behaviour.

În tabloul de bord Jenkinsputeți observa și rezultatele testelor:

Pasul 3 Crearea unui fișier WAR și implementarea pe serverul Tomcat:

Acum, următorul pas este să împachetăm aplicația noastră într-un fișier WAR și să o implementăm pe serverul Tomcat pentru testul de acceptare a utilizatorului.

Creați încă un proiect freestyle și adăugați adresa URL a depozitului de cod sursă.

Apoi, în fila de declanșare a compilării, selectați construirea când sunt construite alte proiecte, luați în considerare captura de ecran de mai jos:

Practic, după lucrarea de testare, faza de implementare va începe automat.

În fila Build, selectați scriptul shell. Tastați comanda de mai jos pentru a împacheta aplicația într-un fișier WAR:

pachet mvn

Următorul pas este să implementați acest fișier WAR pe TomcatServer. În fila „Acțiuni post-construire” selectați implementarea războiului / urechii într-un container. Aici, dați calea către fișierul de război și dați calea contextuală. Luați în considerare captura de ecran de mai jos:

Selectați acreditările Tomcat și observați captura de ecran de mai sus. De asemenea, trebuie să furnizați adresa URL a serverului Tomcat.

Pentru a adăuga acreditări în Jenkins, faceți clic pe opțiunea acreditări de pe tabloul de bord Jenkins.

Faceți clic pe Sistem și selectați acreditări globale.

cum se setează java classpath

Apoi veți găsi o opțiune pentru a adăuga acreditările. Faceți clic pe acesta și adăugați acreditări.

Adăugați acreditările Tomcat, luați în considerare captura de ecran de mai jos.

Faceți clic pe OK.

Acum, în Configurarea proiectului, adăugați acreditările tomcat pe care le-ați inserat în pasul anterior.

Faceți clic pe Salvare și apoi selectați Construiți acum.

Accesați adresa URL tomcat, cu calea contextuală, în cazul meu este http: // localhost: 8081. Acum adăugați calea contextuală la final, luați în considerare imaginea de mai jos:

Link - http: // localhost: 8081 / gof

Sper că ați înțeles sensul căii contextuale.

Acum creați o vizualizare a conductei, luați în considerare captura de ecran de mai jos:

Faceți clic pe pictograma plus, pentru a crea o vizualizare nouă.

Configurați conducta așa cum doriți, luați în considerare captura de ecran de mai jos:

Nu am schimbat nimic în afară de selectarea locului de muncă inițial. Deci, conducta mea va începe de la compilare. Pe baza modului în care am configurat alte joburi, după testarea compilării și implementarea se vor întâmpla.

În cele din urmă, puteți testa conducta făcând clic pe RUN. După fiecare cinci minute, dacă există o modificare a codului sursă, va fi executată întreaga conductă.

Deci, suntem capabili să implementăm în mod continuu aplicația noastră pe serverul de testare pentru testul de acceptare a utilizatorului (UAT).

Sper că v-a plăcut să citiți această postare pe Livrare continuă. Dacă aveți îndoieli, nu ezitați să le puneți în secțiunea de comentarii de mai jos și voi reveni cu un răspuns cel mai devreme.

Pentru a construi conducte CI / CD trebuie să stăpâniți o gamă largă de abilități Stăpâniți acum abilitățile DevOps necesare