DevOps

**DevOps** është një qasje që synon të integrojë dhe të automatizojë proceset e zhvillimit të teknologjisë së informacionit.  DevOps përfshin përfshin praktika që mbështeti  zhvillimit të softuerit dhe synojnë të shkurtojnë kohën e dorezimit, duke përmirsuar ciklin jetesor te zhvillimit t .  Sipas Neal Ford, DevOps, veçanërisht përmes ofrimit të vazhdueshëm, përdor parimin "Sillni dhimbjen përpara", duke trajtuar detyrat e vështira herët, duke nxitur automatizimin dhe zbulimin e shpejtë të problemeve.  Programeret dhe arkitektët e softuerëve duhet të përdorin funksione fitnesi për të mbajtur nën kontroll softuerin e tyre.  Megjithatë, termi përdoret në kontekste të shumta. Në formën e tij më të suksesshme, DevOps është një kombinim i praktikave teknike, ndryshimeve të kulturës dhe mjeteve. 

## Histori 
Propozimet për të bashkuar metodologjitë e zhvillimit të softuerit me konceptet e vendosjes dhe operacioneve filluan të shfaqeshin në fund të viteve 1980 dhe fillim të viteve 1990. 

Në vitin 2009, u organizua në Ghent të Belgjikës konferenca e parë e quajtur *DevOps Days*. Ajo u themelua nga konsulenti belg dhe praktikuesi i metodologjive agile, Patrick Debois.  . Që nga ajo kohë, konferenca është zgjeruar dhe është mbajtur në shumë vende të tjera të botës. 

Në vitin 2012, një raport i quajtur "State of DevOps" u botua për herë të parë nga Alanna Brown në Puppet Labs .  

Që nga viti 2014, raporti vjetor i State of DevOps është publikuar nga Nicole Forsgren, Gene Kim, Jez Humble dhe të tjerë. Ata deklaruan se adoptimi  i DevOps po përshpejtohej.   Gjithashtu në vitin 2014, Lisa Crispin dhe Janet Gregory botuan librin "More Agile Testing", që përmbante një kapitull mbi testimin dhe DevOps.  

Në vitin 2016, metrikat DORA për rendimentin (frekuenca e vendosjes, koha e përgatitjes për ndryshime) dhe stabilitetin (koha mesatare për t'u rikuperuar, shkalla e dështimit të ndryshimeve) u botuan në raportin e Gjendjes së DevOps.     Në përgjigje të këtyre kritikave, raporti i Gjendjes së DevOps 2023  botoi ndryshime që përditësuan metrikën e stabilitetit "koha mesatare për t'u rikuperuar" në "kohë e rikuperimit të vendosjes së dështuar", duke pranuar konfuzionin që ka shkaktuar metrika e mëparshme. 

DevOps Research and Assessment (DORA) ka zhvilluar një seri metrikash që synojnë të matin efikasitetin dhe besueshmërinë e procesit të zhvillimit të softuerëve. Këto metrika përfshijnë:  

* Frekuenca e Vendosjes: Koha midis vendosjeve të kodit.
* Koha Mesatare e Përgatitjes për Ndryshime: Koha midis kryerjes së kodit dhe vendosjes.
* Shkalla e Dështimit të Ndryshimeve: Përqindja e vendosjeve që shkaktojnë probleme në prodhim.
* Koha e Rimëkëmbjes pas Dështimit të Vendosjes (më parë Koha Mesatare për Rimëkëmbje)
* Besueshmëria (shtuar në vitin 2021): Mat performancën operative, duke u përqendruar në disponueshmërinë dhe përmbushjen e pritjeve të përdoruesit.

## Marrëdhënia me qasjet e tjera 
Shumë nga idetë themelore për praktikat DevOps janë të frymëzuara nga, praktika të tjera të njohura, të tilla si cikli Planifiko-Bëj-Kontrollo-Vepro i Lean dhe Deming, deri te Mënyra Toyota dhe qasja Agile e ndarjes së komponentëve dhe madhësive të serive.  Ndryshe nga qasja përshkruese "nga lart-poshtë" dhe kuadri i ngurtë i ITIL në vitet 1990, DevOps është "nga poshtë-lart" dhe fleksibël, pasi është krijuar nga inxhinierët e softuerëve për nevojat e tyre. 

### Inxhinieri platformash 
**Inxhinieria e platformave** është një disiplinë në zhvillim e sipër brenda inxhinierisë së softuerëve që mbështet DevOps duke ndërtuar dhe mirëmbajtur platforma të brendshme zhvilluesish (IDP). Këto platforma ofrojnë mjete të standardizuara dhe komponentë të ripërdorshëm - të tilla si tubacionet CI/CD, sigurimi i infrastrukturës, vëzhgueshmëri dhe kontrolle sigurie - për të përmirësuar ofrimin e softuerëve dhe për të zvogëluar ngarkesën njohëse te zhvilluesit. Qëllimi është të mundësohen aftësitë e vetëshërbimit, të përmirësohet produktiviteti dhe të sigurohet qëndrueshmëri në të gjitha ekipet e zhvillimit dhe operacioneve.  

### Shkathtësia 
Motivimet për atë që është bërë DevOps modern dhe disa praktika standarde DevOps, të tilla si ndërtimi dhe testimi i automatizuar, qasja e i vazhdueshme dhe ofrimi i vazhdueshëm, e kanë origjinën në botën Agile, e cila daton (joformalisht) në vitet 1990 dhe zyrtarisht në vitin 2001. Ekipet e zhvillimit Agile(të Shkathtesisë) që përdorin metoda të tilla si programimi ekstrem nuk mund ta "kënaqnin klientin përmes ofrimit të hershëm dhe të vazhdueshëm të softuerit të vlefshëm"  nëse nuk merrnin përgjegjësinë për operacionet dhe infrastrukturën për aplikacionet e tyre, duke automatizuar pjesën më të madhe të asaj pune. Meqenëse Scrum doli si kuadri dominues Agile në fillim të viteve 2000 dhe hoqi dorë nga praktikat inxhinierike që ishin pjesë e shumë ekipeve Agile, lëvizja për të automatizuar operacionet dhe funksionet e infrastrukturës u nda nga Agile dhe u zgjerua në atë që është bërë DevOps modern. Sot, DevOps përqendrohet në vendosjen e softuerit të zhvilluar, pavarësisht nëse është zhvilluar duke përdorur metodologji të orientuara drejt Agile apo metodologji të tjera.

### ArchOps 
ArchOps është një zgjerim i praktikave DevOps që fokusohet tek artefaktet e  arkitekturës së softuerit, në vend të kodit burimor, për proceset e vendosjen së operacioneve.  Sipas ArchOps, modelet arkitekturore konsiderohen entitete të klasit të parë në zhvillimin, vendosjen dhe menaxhimin e sistemeve të softuerit.

### Qasje dhe Ofrim i Vazhdueshëm (CI/CD) 
Automatizimi është një parim thelbësor për arritjen e suksesit në DevOps ndërsa CI/CD përfaqëson një komponent kritik në këtë proces.  Për më tepër, bashkëpunimi dhe komunikimi i përmirësuar midis dhe brenda ekipeve ndihmon në arritjen e një kohe më të shpejtë në treg, me rreziqe të reduktuara. 

### DevOps i Bazës së të Dhënave 
Baza e të Dhënave DevOps zbaton parimet DevOps dhe CI/CD drejtpërdrejt në zhvillimin dhe operacionet e bazës së të dhënave. Integrimi i ndryshimeve të skemës, migrimeve, të dhënave referuese dhe përditësimeve të tjera të shtresës së të dhënave në të njëjtat kanale të kontrolluara nga versioni dhe të automatizuara që përdoren për kodin e aplikacionit mundëson vendosje më të besueshme dhe koordinim më të mirë midis ndryshimeve të aplikacionit dhe të dhënave.  

Praktikat e zakonshme të dokumentuara në literaturën kërkimore dhe standardet e industrisë përfshijnë vendosjen e përkufizimeve të skemës së bazës së të dhënave nën kontrollin e versionit, zbatimin e testeve të automatizuara (si testet e njësive ose validimi i migrimeve) mbi ndryshimet e bazës së të dhënave, dhe vendosjen e këtyre ndryshimeve përmes kanaleve CI/CD. Këto praktika ndihmojnë në zvogëlimin e "zhvendosjes së skemës" midis sistemeve të zhvillimit dhe prodhimit dhe reduktojnë rrezikun e dështimeve gjatë vendosjes.  

### Devops per celular 
DevOps-i celular është një grup praktikash që aplikon parimet e DevOps në mënyrë të veçantë për zhvillimin e aplikacioneve celulare. Ndërsa DevOps tradicional synon përmirësimin procesit të zhvillimit të softuerit në përgjithësi, por zhvillimi celular ka sfidat e veta unike që kërkojnë një qasje të përshtatur.  DevOps-i celular nuk është thjesht një degë e DevOps-it specifik për zhvillimin e aplikacioneve celulare, por një zgjerim dhe riinterpretim i filozofisë DevOps për shkak të kërkesave shumë specifike të botës mobile.

### Inxhinieri e besueshmërisë së vendndodhjes 
Në vitin 2003, Google zhvilloi inxhinierinë e besueshmërisë së faqes (SRE), një qasje për lëshimin e vazhdueshëm të veçorive të reja në sisteme me disponueshmëri të lartë dhe në shkallë të gjerë, duke ruajtur njëkohësisht përvojën e përdoruesit  me cilësi të lartë.  Ndërsa SRE ka egzistuar para DevOps, ato zakonisht shihen si të lidhura me njëra-tjetrën. Disa nga autorët origjinalë të disiplinës e shohin SRE si një zbatim të DevOps. 

### Sistemi i prodhimit Toyota 
Sistemi i prodhimit të Toyota-s, i njohur edhe me akronimin TPS, ishte frymëzimi për të menduarit e ligët me fokusin e tij në përmirësimin e vazhdueshëm, kaizen, rrjedhshmërinë dhe sasitë e vogla. Parimi i kordonit andon përdoret për të krijuar reagime të shpejta, grumbullimin dhe zgjidhjen e problemeve rrjedh nga TPS.  

### DevSecOps, zhvendosja e sigurisë majtas 
**DevSecOps** është një zgjerim i DevOps që synon integrimin e praktikave të sigurisë në proceset DevOps. Ndryshe nga modeli tradicional me një ekip qendror të sigurisë, çdo ekip shpërndarjeje ka autoritetin të përfshijë kontrollet e nevojshme të sigurisë në shpërndarjen e softuerit të tyre. Praktikat dhe testimet e sigurisë kryhen më herët gjatë ciklit jetësor të zhvillimit, duke përfshirë konceptin e njohur si " zhvendosje majtas ". Siguria testohet kryesisht në tre fusha kryesore:analiza  statike, analiza përbërjes se softuerit dhe testimi dinamik.

Kontrollimi statik i softuerit realizohet permes testimit statik të sigurisë së aplikacioneve (SAST) është testim i kutisë së bardhë me fokus të veçantë në siguri. Në varësi të gjuhës së programimit, përdoren mjete të ndryshme për të analizuar të statikisht kodin. Analizohet përbërja e softuerit, veçanërisht bibliotekat, dhe versioni i secilit komponent kontrollohet kundrejt listave të cenueshmërisë të publikuara nga CERT dhe grupe të tjera ekspertësh. Kur u jepen softuer klientëve, në fokus janë licencat e bibliotekave dhe përputhja e tyre me licencën e softuerit të shpërndarë, veçanërisht licencat e të drejtës së autorit .

Testimin dinamik, i njohur edhe si testim i kutisë së zezë, softueri testohet pa ditur funksionet e tij të brendshme. Në kuadër të DevSecOps, kjo praktikë njihet si testim dinamik i sigurisë së aplikacionit (DAST) ose testim i depërtimit. Qëllimi është identifikimi i hershëm i defekteve, duke përfshirë skriptimin ndërfaqësor dhe dobësitë e injektimit SQL .

Shpesh, defektet e zbuluara nga testimet statike dhe dinamike kategorizohen sipas taksonomive si Common Weakness Enumeration (CWE), e mirëmbajtur nga Mitre Corporation . Kjo ndihmon caktimin e përparësive të rregullimeve të gabimeve të sigurisë dhe gjithashtu mundeson që dobësitë që përsëriten shpesh të zgjedhen me zbutjet e rekomanduara. Që nga viti 2025, CWE mbante listën e vet të dobësive që ndodhin shpesh, CWE Top 25.  Përveç kësaj, organizata si Open Worldwide Application Security Project (OWASP) mbajnë lista të dobësive të softuerëve që përsëriten shpesh në të gjithë industrinë. 

DevSecOps është përshkruar gjithashtu si një ndryshim kulturor që përfshin një qasje të përgjithshme për prodhimin e softuerëve të sigurt duke integruar edukimin mbi sigurinë, sigurinë sipas dizajnit dhe automatizimin e sigurisë. 

## Kulturë 
Iniciativat  e DevOps mund të ndryshojnë mënyrën se si operacionet, zhvilluesit dhe testuesit e një kompanie bashkëpunojnë gjatë proceseve të zhvillimit dhe ofrimit të shërbimeve.  

DevOps synon të mbështesë qëndrueshmërinë, besueshmërinë dhe efikasitetin brenda një organizate. Kjo zakonisht mundësohet nga një depo e përbashkët kodi ose kontrolli i versionit.  Shumë organizata përdorin kontrollin e versionit për të lehtësuar teknologjitë e automatizimit DevOps si makinat virtuale, kontejnerizimin (ose virtualizimin në nivel sistemi operativ ) dhe CI/CD,  me sistemin e kontrollit të versionit Git dhe platformën GitHub të referuara si shembuj.

## GitOps 
GitOps ka evoluar nga DevOps. Gjendja specifike e konfigurimit të vendosjes është e kontrolluar nga versioni . Meqenëse kontrolli i versionit më i popullarizuar është Git, qasja GitOps është emëruar sipas Git. Ndryshimet në konfigurim mund të menaxhohen duke përdorur praktikat e rishikimit të kodit dhe mund të anulohen duke përdorur kontrollin e versionit. Në thelb, të gjitha ndryshimet në një kod gjurmohen, shënohen dhe bërja e çdo përditësimi në histori mund të bëhet më e lehtë. Siç shpjegohet nga Red Hat, "dukshmëria ndaj ndryshimit do të thotë aftësia për të gjurmuar dhe riprodhuar problemet shpejt, duke përmirësuar sigurinë e përgjithshme." 

## Praktikat më të mira për sistemet cloud 
Praktikat e mëposhtme mund të rrisin produktivitetin e kanaleve DevOps, veçanërisht në sistemet e hostuara në cloud :   

* **Numri i Rrjedhave të Informacionit** : Ekipet e vogla mund të jenë më produktive duke pasur një depo dhe një kanal. Në të kundërt, organizatat më të mëdha mund të kenë depo dhe kanale të veçanta për secilin ekip ose edhe depo dhe kanale të veçanta për secilin shërbim brenda një ekipi.
* **Lejet** : Në kontekstin e lejeve që lidhen me tubacionin, respektimi i parimit të privilegjit më të vogël mund të jetë sfidues për shkak të natyrës dinamike të arkitekturës . Administratorët mund të zgjedhin leje më lejuese, ndërsa zbatojnë kontrolle sigurie kompensuese për të minimizuar rrezen e shpërthimit.

## Shiko edhe 
## Referime