Dacă ești nou în DevOps, aruncă o privire asupra acestui ghid pentru a-ți crea primul pipeline în cinci etape.
DevOps a devenit soluția standard pentru remedierea proceselor de dezvoltare software lente, fragmentate sau ineficiente. Problema este că, dacă ești novice în DevOps și nu știi de unde să începi, s-ar putea să îți lipsească înțelegerea acestor metode. În acest articol, vom defini pipeline-ul DevOps și va fi oferit un ghid pentru a-l crea în cinci pași. Deși acest ghid nu este exhaustiv, ar trebui să îți ofere o bază pentru a-ți începe călătoria și a-ți extinde cunoștințele în viitor. Dar să începem cu o poveste.
Călătoria mea în DevOps
În trecut, am lucrat în echipa de cloud a Citi Group, dezvoltând o aplicație web Infrastructure-as-a-Service (IaaS) pentru gestionarea infrastructurii cloud a Citi, dar am fost mereu interesat de cum să fac procesul de dezvoltare mai eficient și să aduc schimbări culturale pozitive în echipa de dezvoltare. Răspunsul l-am găsit în cartea recomandată de Greg Lavender, directorul tehnic al Citi pentru arhitectura cloud și infrastructură. Cartea se numea „Proiectul Fenix” (), și explică principiile DevOps, fiind citită ca un roman.
În tabelul de pe coperta din spate a cărții se arată cât de des diferite companii își desfășoară sistemele în mediul de lansare a versiunilor:
Amazon: 23.000 pe zi
Google: 5.500 pe zi
Netflix: 500 pe zi
Facebook: O dată pe zi
Twitter: De 3 ori pe săptămână
O companie tipică: O dată la 9 luni
Cum sunt posibile frecvențele Amazon, Google și Netflix? Totul deoarece aceste companii au găsit soluția pentru a crea un pipeline DevOps aproape perfect.
Am fost departe de acest lucru până când am implementat DevOps în Citi. Atunci, echipa mea avea medii diverse, dar desfășurarea pe serverul de dezvoltare era complet manuală. Toți dezvoltatorii aveau acces doar la un singur server de dezvoltare bazat pe IBM WebSphere Application Server Community Edition. Problema era că serverul se închidea de fiecare dată când mai mulți utilizatori încercau simultan să efectueze desfășurarea, așa că dezvoltatorii trebuiau să își comunice intențiile, ceea ce era destul de dificil. În plus, existau probleme cu acoperirea testelor la nivel de cod, cu procesele voluminoase de desfășurare manuală și cu lipsa posibilității de a urmări desfășurarea codului legată de o anumită sarcină sau poveste utilizator.
Am realizat că trebuie să fac ceva și am găsit un coleg cu aceleași viziuni. Am decis să colaborăm pentru a crea prima versiune a conveiului nostru DevOps – el a configurat o mașină virtuală și serverul de aplicații Tomcat, în timp ce eu am lucrat la Jenkins, am integrat Atlassian Jira și BitBucket și am lucrat la acoperirea testelor de cod. Acest proiect lateral a fost foarte de succes: am automatizat aproape complet multe procese, am obținut o funcționalitate de aproape 100% a serverului nostru de dezvoltare, am asigurat urmărirea și am îmbunătățit acoperirea testului de cod, precum și am adăugat posibilitatea de a lega ramuri în Git de sarcini în Jira sau desfășurări. Majoritatea instrumentelor pe care le-am folosit pentru a construi conveiul nostru DevOps erau cu sursă deschisă.
Acum înțeleg cât de simplu era conveiul nostru DevOps: nu foloseam extensii precum Jenkins files sau Ansible. Cu toate acestea, acest conveiu simplu a funcționat bine, poate datorită principiului Pareto (cunoscut și sub numele de regula 80/20).
Introducere scurtă în DevOps și conveiul CI/CD
Dacă întrebați câțiva oameni: „Ce este DevOps?”, probabil veți obține câteva răspunsuri diferite. DevOps, la fel ca Agile, a evoluat pentru a cuprinde multe discipline diferite, dar majoritatea oamenilor vor fi de acord cu anumite lucruri: DevOps este o practică de dezvoltare software sau un ciclu de viață al dezvoltării software (SDLC), al cărei principiu central este schimbarea culturii în care dezvoltatorii și non-dezvoltatorii coexistă într-un mediu în care:
Operațiunile care erau anterior efectuate manual sunt automatizate;
Fiecare face ceea ce știe să facă cel mai bine;
Numărul de implementări pe o anumită perioadă de timp crește; Capacitatea de lucru crește;
Flexibilitatea dezvoltării crește.
Deși a avea instrumentele software potrivite nu este singurul lucru necesar pentru a crea un mediu DevOps, unele instrumente sunt esențiale. Un instrument cheie este integrarea continuă și livrarea continuă (CI/CD). În această conductă, mediile au diferite etape (de exemplu, DEV, INT, TST, QA, UAT, STG, PROD), multe operațiuni sunt automatizate, iar dezvoltatorii pot scrie cod de calitate superioară, obținând flexibilitate în dezvoltare și frecvență ridicată a livrărilor.
Acest articol descrie o abordare în cinci pași pentru a crea un conductă DevOps, similară cu cea ilustrată în diagrama următoare, folosind instrumente cu sursă deschisă.
Pasul 1: Metode CI/CD
Primul lucru de care aveți nevoie este un instrument pentru CI/CD. Jenkins, un instrument cu sursă deschisă bazat pe Java și distribuit sub licența MIT, este acel instrument care a popularizat direcția DevOps și a devenit standardul de facto.
Ce este Jenkins mai exact? Considerați-l un fel de telecomandă magică universală care poate comunica cu diverse servicii și instrumente și le poate organiza. De unul singur, un instrument CI/CD, cum ar fi Jenkins, este inutil, dar devine mai puternic pe măsură ce se conectează la diverse instrumente și servicii.
Jenkins este doar unul dintre cele multe instrumente cu sursă deschisă pentru CI/CD pe care le puteți folosi pentru a construi un conductă DevOps.
Jenkins: Creative Commons și MIT
Travis CI: MIT
CruiseControl: BSD
Buildbot: GPL
Apache Gump: Apache 2.0
Cabie: GNU
Iată cum arată procesele DevOps cu un instrument CI/CD:
Aveți un instrument CI/CD care funcționează pe localhost, dar în prezent nu puteți face prea multe. Să trecem la următoarea etapă a călătoriei în lumea DevOps.
Pasul 2: Gestionarea sistemelor de control al versiunilor
Cea mai bună (și, poate, cea mai simplă) modalitate de a verifica dacă instrumentul dvs. CI/CD poate face minuni este să se integreze cu un instrument de control al surselor (SCM). De ce aveți nevoie de controlul surselor? Presupunând că dezvoltați o aplicație. De fiecare dată când creați o aplicație, programați, iar acest lucru este valabil indiferent dacă folosiți Java, Python, C++, Go, Ruby, JavaScript sau unul dintre zecile de mii de limbaje de programare. Codul pe care îl scrieți se numește cod sursă. La început, mai ales când lucrați singur, este probabil că puteți pune totul într-un director local. Dar când proiectul devine mai mare și invitați alte persoane să colaboreze, aveți nevoie de o modalitate de a preveni conflictele în timp ce partajați modificările eficient. De asemenea, aveți nevoie de o modalitate de a recupera versiunile anterioare, deoarece crearea de copii de rezervă și copierea/înserarea acestora este deja depășită. Aveți (și echipa dvs.) nevoie de ceva mai bun.
Aici este unde un instrument de control al versiunilor devine practic necesar. Acest instrument păstrează codul dvs. în depozite, ține evidența versiunilor și coordonează activitatea participanților la proiect.
Deși există multe instrumente de control al surselor, Git este standardul, și este adevărat. Vă recomand cu căldură să utilizați Git, deși există și alte opțiuni cu sursă deschisă, dacă preferați.
Git: GPLv2 și LGPL v2.1
Subversion: Apache 2.0
Concurrent Versions System (CVS): GNU
Vesta: LGPL
Mercurial: GNU GPL v2+
Iată cum arată un pipeline DevOps cu instrumentele de control al surselor adăugate.
Instrumentul CI/CD poate automatiza procesele de verificare, obținere a codului sursă și colaborare între membri. Nu este rău? Dar cum transformăm asta într-o aplicație funcțională, astfel încât miliarde de oameni să o poată utiliza și aprecia?
Pasul 3: Crearea instrumentului de automatizare a construcției
Excelent! Puteți verifica codul și face modificări în sistemul de control al versiunilor, precum și invita prietenii să colaboreze la dezvoltare. Dar nu ați creat încă o aplicație. Pentru a face o aplicație web, trebuie să fie compilată și împachetată într-un format de pachet desfășurabil sau să fie rulată ca un fișier executabil. (Rețineți că un limbaj de programare interpretat, cum ar fi JavaScript sau PHP, nu necesită compilare).
Utilizați un instrument de automatizare a construirii. Indiferent de instrumentul de automatizare a construirii pe care decideți să-l folosiți, toate au același scop: de a procesa codul sursă într-un format dorit și de a automatiza sarcini precum curățAREA, compilAREA, testAREA și desfășurAREA în medii specifice. Instrumentele de construire vor varia în funcție de limbajul dumneavoastră de programare, dar iată câteva opțiuni comune cu sursă deschisă.
Denumire
Licență
Limbaj de programare
Maven
Apache 2.0
Java
Ant
Apache 2.0
Java
Gradle
Apache 2.0
Java
Bazel
Apache 2.0
Java
Make
GNU
N/A
Grunt
MIT
JavaScript
Gulp
MIT
JavaScript
Buildr
Apache
Ruby
Rake
MIT
Ruby
A-A-P
GNU
Python
SCons
MIT
Python
BitBake
GPLv2
Python
Cake
MIT
C#
ASDF
Expat (MIT)
LISP
Cabal
BSD
Haskell
Minunat! Puteți plasa fișierele de configurare ale instrumentului de automatizare a construirii în sistemul de control al versiunilor și permiteți instrumentului dumneavoastră CI/CD să le integreze.
Totul este bine, nu-i așa? Dar unde veți desfășura aplicația dumneavoastră?
Pasul 4: Server pentru aplicații web
Până acum aveți un fișier împachetat care poate fi fie executabil, fie instalabil. Pentru ca orice aplicație să fie cu adevărat utilă, ea trebuie să ofere un serviciu sau o interfață, dar aveți nevoie de un container pentru a găzdui aplicația.
Serverul pentru aplicații web este exact acel container. Serverul oferă un mediu în care poate fi definită logica pachetului desfășurat. De asemenea, serverul oferă o interfață și oferă servicii web, deschizând socket-uri către lumea externă. Aveți nevoie de un server HTTP, precum și de un mediu (de exemplu, o mașină virtuală) pentru instalarea sa. Între timp, să presupunem că veți învăța despre acest lucru mai târziu (deși vă voi vorbi despre containere mai jos).
Există mai multe servere pentru aplicații web cu sursă deschisă.
Denumire
Licență
Limbaj de programare
Tomcat
Apache 2.0
Java
Jetty
Apache 2.0
Java
WildFly
GNU Lesser Public
Java
GlassFish
CDDL & GNU Less Public
Java
Django
3-Clause BSD
Python
Tornado
Apache 2.0
Python
Gunicorn
MIT
Python
Python
MIT
Python
Rails
MIT
Ruby
Node.js
MIT
Javascript
Pipelines-ul tău DevOps este aproape gata de utilizare. Bună treabă!
Deși te poți opri aici și să te ocupi de integrare pe cont propriu, calitatea codului este un aspect important pentru dezvoltatorii de aplicații, și trebuie să fie o preocupare.
Pasul 5: Acoperirea testării codului
Implementarea testelor poate fi o altă cerință voluminoasă, dar dezvoltatorii trebuie să prindă orice eroare în aplicație din fazele incipiente și să îmbunătățească calitatea codului pentru a garanta că utilizatorii finali vor fi mulțumiți. Din fericire, există o mulțime de instrumente open-source pentru a testa codul tău și a oferi sugestii de îmbunătățire a acestuia. Mai bine, majoritatea instrumentelor CI/CD pot fi integrate cu aceste unelte și pot automatiza procesul.
Testarea codului se împarte în două părți: framework-uri de testare a codului, care ajută la scrierea și execuția testelor, și instrumente care oferă sugestii pentru îmbunătățirea calității codului.
Sisteme de testare a codului
Denumire
Licență
Limbaj de programare
JUnit
Licența Publică Eclipse
Java
EasyMock
Apache
Java
Mockito
MIT
Java
PowerMock
Apache 2.0
Java
Pytest
MIT
Python
Hypothesis
Mozilla
Python
Tox
MIT
Python
Sisteme de recomandare pentru îmbunătățirea codului
Denumire
Licență
Limbaj de programare
Cobertura
GNU
Java
CodeCover
Eclipse Public (EPL)
Java
Coverage.py
Apache 2.0
Python
Emma
Licența Publică Comună
Java
JaCoCo
Licența Publică Eclipse
Java
Hypothesis
Mozilla
Python
Tox
MIT
Python
Jasmine
MIT
JavaScript
Karma
MIT
JavaScript
Mocha
MIT
JavaScript
Jest
MIT
JavaScript
Reține că majoritatea instrumentelor și framework-urilor menționate mai sus sunt scrise pentru Java, Python și JavaScript, deoarece C++ și C# sunt limbaje de programare proprietare (deși GCC are cod sursă deschis).
Acum că ai implementat instrumentele de acoperire a codului cu teste, pipeline-ul tău DevOps ar trebui să arate ca diagrama prezentată la începutul acestui ghid.
Pași suplimentari
Containere
Așa cum am menționat, poți găzdui serverul pe o mașină virtuală sau pe un server, dar containerele sunt o soluție populară.
Ce sunt containerele? Pe scurt, o mașină virtuală necesită o cantitate considerabilă de memorie pentru sistemul de operare, depășind dimensiunea aplicației, în timp ce un container are nevoie doar de câteva biblioteci și configurații pentru a rula aplicația. Evident, o mașină virtuală are încă aplicații importante, dar un container este o soluție ușoară pentru găzduirea aplicației, inclusiv a serverului de aplicații.
Deși există și alte tipuri de containere, cele mai populare sunt Docker și Kubernetes.
Docker: Apache 2.0
Kubernetes: Apache 2.0
Instrumente intermediare de automatizare
Pipeline-ul nostru DevOps se concentrează în principal pe colaborarea în crearea și desfășurarea aplicațiilor, dar există multe alte lucruri care pot fi realizate cu instrumentele DevOps. Unul dintre acestea este utilizarea instrumentelor Infrastructure as Code (IaC), care sunt cunoscute și sub numele de instrumente intermediare de automatizare. Aceste instrumente ajută la automatizarea instalării, gestionării și altor sarcini pentru software-ul intermediar. De exemplu, un instrument de automatizare poate extrage aplicații precum serverul aplicațiilor web, baza de date și instrumentul de monitorizare, cu configurațiile corecte și le poate desfășura pe serverul aplicațiilor.
Iată câteva instrumente intermediare de automatizare cu sursă deschisă:
Ansible: GNU Public
SaltStack: Apache 2.0
Chef: Apache 2.0
Puppet: Apache sau GPL
Aflați detaliile despre cum să obțineți o profesie solicitată de la zero sau să faceți un Level Up pentru abilități și salariu, parcurgând cursurile online cu plată SkillFactory:
- (12 luni)
alte cursuri
- (12 săptămâni)
- (12 luni)
- (9 luni)
- (9 luni)
Util
Sursa: habr.com
