Jenkins, GitHub Actions și GitLab CI sunt toate opțiuni pentru echipele care au nevoie de o platformă CI/CD. Alegerea potrivită depinde mai puțin de popularitate și mai mult de modul în care echipa dorește să configureze fluxurile de lucru, să execute sarcini, să protejeze informațiile confidențiale, să conecteze implementările, să gestioneze infrastructura, să controleze costurile și să mențină portabilitatea.
CI/CD înseamnă Integrare Continuă și Implementare Continuă. Este o metodă automatizată de creare, testare și livrare a modificărilor de cod. În loc să aștepte actualizări manuale de amploare, o echipă poate utiliza pași automatizați pentru a livra modificări mai mici, cu verificări mai consistente. Aflați mai multe despre CI/CD.
Cuprins
Începeți cu modelul operațional
Prima decizie pe care trebuie să o ia echipa este dacă dorește un pipeline găzduit, unul autogestionat sau o combinație între cele două. O abordare găzduită reduce volumul de infrastructură pe care echipa trebuie să o gestioneze. O abordare autogestionată oferă organizației un control mai direct asupra mediului pipeline-ului, dar echipa își asumă și responsabilitatea pentru configurare, actualizări, acces și întreținerea continuă.
Niciunul dintre modele nu este automat mai bun. O echipă mică poate aprecia un proces de configurare scurt și o întreținere redusă. O organizație mai mare poate avea nevoie de un control mai strict asupra locului în care se execută sarcinile și a modului în care este gestionat accesul. O echipă care intenționează să treacă de la o platformă la alta ar trebui, de asemenea, să trateze portabilitatea ca pe o cerință de proiectare încă de la început.
Comparați configurația fluxului de lucru
Configurația fluxului de lucru definește momentul în care începe un pipeline și pașii pe care îi execută. Pașii tipici includ compilarea unei aplicații, rularea testelor și implementarea unei modificări. O comparație utilă ar trebui să analizeze cât de clar exprimă pipeline-ul aceste etape, cât de ușor este să se revizuiască modificările și cum se potrivește configurația cu procesul de dezvoltare existent al echipei.
- Jenkins: evaluează modul în care echipa va defini, revizui și menține configurația pipeline-ului în mediul ales.
- GitHub Actions: evaluează modul în care configurația fluxului de lucru se potrivește cu procesul existent al echipei bazat pe GitHub.
- GitLab CI: evaluați modul în care configurația fluxului de lucru se integrează în procesul existent al echipei, bazat pe GitLab.
Decizia importantă nu este cea mai scurtă exemplificare de pipeline. Analizați întregul ciclu de viață: o modificare obișnuită, un test eșuat, o aprobare manuală, o revenire la o versiune anterioară și o modificare a pipeline-ului în sine. O configurație ușor de înțeles în toate aceste cazuri este mai utilă decât una care pare simplă doar la început.
Runner-ii determină locul în care se execută sarcinile
Un runner este mediul în care se execută o sarcină CI/CD. Atunci când comparați platformele, identificați cine furnizează acel mediu și cine îl întreține. Runnerii găzduiți pot reduce efortul legat de infrastructură. Runnerii autogestionați pot oferi organizației un control mai mare asupra mediului de execuție și a accesului la rețea.
Deciziile privind runner-ul afectează efortul de configurare, evaluarea securității, scalarea și întreținerea. De asemenea, acestea influențează costurile, deoarece organizația trebuie să țină cont atât de utilizarea pipeline-ului, cât și de personalul sau sistemele necesare pentru operarea infrastructurii autogestionate. Documentați instrumentele necesare, permisiunile, căile de rețea și responsabilitățile operaționale înainte de a selecta o platformă.
Verificați secretele și accesul la implementare
Secretele sunt valori sensibile utilizate de un pipeline, cum ar fi datele de autentificare sau token-urile de implementare. Comparația ar trebui să acopere locul în care sunt stocate secretele, care etape ale fluxului de lucru le pot utiliza, modul în care accesul este limitat și modul în care sunt înlocuite datele de autentificare.
Integrările de implementare ar trebui evaluate în același mod. Enumerați mediile care trebuie să primească versiunile, punctele de aprobare necesare înainte de implementare și datele de autentificare necesare pentru fiecare destinație. Apoi, confirmați că platforma selectată poate susține acest proces fără a acorda fiecărei sarcini acces nelimitat.
Întreținere, scalabilitate și cost total
Întreținerea include actualizări ale configurației pipeline-ului, ale mediilor de execuție, ale integrărilor, ale permisiunilor și ale controalelor de securitate. Pipeline-urile găzduite pot reduce infrastructura pe care o gestionează echipa. Pipeline-urile autogestionate pot necesita mai mult efort operațional, oferind însă organizației un control mai mare. Acestea sunt compromisuri legate de modelul operațional, nu simple clasamente de calitate.
Costul total ar trebui să includă mai mult decât prețul produsului sau al utilizării. Luați în calcul timpul de configurare, infrastructura de execuție, spațiul de stocare, execuția pipeline-urilor, activitățile de integrare, verificările de securitate, depanarea, actualizările și timpul personalului necesar pentru întreținerea sistemului. Comparați costul aceluiași volum de muncă pe întreaga perioadă de creștere preconizată, în loc să luați în considerare doar prima lună.
Alegeți în funcție de situația echipei
Start-up-uri și echipe mici
Acordați prioritate unui parcurs scurt de la modificarea codului până la compilare, testare și implementare. Un model găzduit poate fi un punct de plecare rezonabil atunci când reducerea efortului de configurare și întreținere este cea mai importantă. Mențineți definițiile fluxului de lucru clare și evitați complexitatea inutilă specifică platformei, astfel încât migrarea viitoare să rămână posibilă.
Echipe de nivel enterprise
Acordați prioritate controlului accesului, guvernanței runner-urilor, aprobărilor de implementare, cerințelor de audit, scalabilității și clarității responsabilităților. Stabiliți care responsabilități revin echipei centrale a platformei și care revin echipelor individuale de produs. Evaluați întregul proces operațional, nu doar sintaxa fluxului de lucru.
Organizații care caută flexibilitate din partea furnizorilor
Acordați prioritate portabilității. Mențineți logica pipeline-ului ușor de înțeles, separați datele de autentificare pentru implementare de codul fluxului de lucru, documentați cerințele executorului și evitați cuplarea fiecărui pas la un serviciu unic al unei platforme. Testați modul în care un flux de lucru reprezentativ ar putea fi mutat înainte ca organizația să se afle sub presiunea timpului.
O regulă practică de selecție
Alegeți platforma al cărei model de operare se potrivește cu constrângerile echipei. Preferați opțiunea care reduce efortul de configurare și întreținere atunci când echipa are nevoie de viteză de livrare, dar capacitatea platformei este limitată. Preferați opțiunea care oferă controlul necesar atunci când securitatea, accesul la rețea, guvernanța sau responsabilitatea pentru execuție sunt cerințe esențiale. Preferați opțiunea care menține portabilitatea configurației și a integrărilor atunci când obiectivul principal este evitarea dependenței de platformă.
CI/CD funcționează cel mai bine atunci când fluxul de lucru este tratat ca o parte întreținută a sistemului software. Controlul versiunilor poate urmări modificările fișierelor site-ului web, poate sprijini colaborarea și poate ajuta la restaurarea versiunilor anterioare, motiv pentru care modificările pipeline-ului și ale aplicației ar trebui revizuite ca parte a procesului normal de dezvoltare al echipei. Aflați cum sprijină controlul versiunilor modificările aduse site-ului web.