Përshëndetje, Habr! Unë paraqes në vëmendjen tuaj një përkthim të artikullit nga Steve Mezak.
Në varësi të këndvështrimit tuaj, DevOps do të festojë përvjetorin e nëntë ose të dhjetë këtë vit. Në vitin 2016, raporti i gjendjes së resë së RightScales vuri në dukje se 70 për qind e SMB-ve po adoptojnë praktikat e DevOps. Çdo tregues që përbën këtë rezultat është rritur që atëherë. Ndërsa DevOps përgatitet të hyjë në dekadën e tij të dytë, do të ishte mirë të bëni një shëtitje në të kaluarën dhe t'i ktheheshit origjinës së DevOps - madje edhe origjinës së vetë emrit.
Para 2007: Një zinxhir i përsosur ngjarjesh
Përpara vitit 2007, një sërë rrethanash përfundimisht lindën atë që sot njihet si DevOps.
Ligët tashmë është dëshmuar se është praktika më e mirë. Gjithashtu i njohur si Sistemi i prodhimit të Toyota, Lean Manufacturing përpiqet të optimizojë proceset në katin e prodhimit. (Meqë ra fjala, menaxhimi i Toyota-s fillimisht u frymëzua nga metodat origjinale të linjës së montimit të prezantuara nga Kompania Ford Motor). Përmirësim të vazhdueshëm është mantra për prodhim të dobët. Në praktikë, shtigjet e mëposhtme vlerësohen vazhdimisht:
- Ruajtja e nivelit të inventarit të lëndëve të para dhe produkteve të gatshme në minimum. Prodhim i dobët nënkupton një sasi minimale të inventarit të lëndëve të para për të prodhuar mallra dhe një sasi minimale të produkteve të gatshme që presin të porositen ose dërgohen.
- Minimizimi i radhës së porosive. Në mënyrë ideale, urdhrat e marra kalojnë menjëherë në gjendjen e përfunduar. Metrika kryesore për prodhimin e dobët do të jetë gjithmonë koha nga marrja e porosisë deri në dorëzim.
- Maksimizimi i efikasitetit të procesit të prodhimit. Ri-inxhinierimi i procesit dhe automatizimi i përmirësuar po kombinohen për të prodhuar mallra sa më shpejt të jetë e mundur. Çdo zonë e prodhimit përgjatë gjithë rrugës (prerje, saldim, montim, testim, etj.) vlerësohet për joefikasitet.
Në botën e TI-së, metodat tradicionale të modelit ujëvarë të zhvillimit të softuerit tashmë i kanë lënë vendin metodave të shpejta përsëritëse si p.sh. i shkathët. Shpejtësia ishte thirrja kryesore, edhe nëse cilësia ndonjëherë vuante në ndjekje të zhvillimit dhe vendosjes së shpejtë. Në të njëjtën mënyrë, në veçanti, kompjuteri cloud Infrastruktura-si-një Shërbim (IaaS) dhe Platforma-si-a-Service (PaaS) e kanë provuar veten si zgjidhje të pjekura në proceset dhe infrastrukturën e IT.
Së fundi, paketat e veglave kanë filluar të shfaqen kohët e fundit për Integrimi i vazhdueshëm (CI). Ideja e mjeteve CI lindi dhe u prezantua nga Gradi Booch në vitin 1991 në Metodën e tij Booch.
2007-2008: Belg i zhgënjyer
Konsulenti belg, menaxheri i projektit dhe praktikës Agile, Patrick Debois, ka pranuar një takim nga një ministri e qeverisë belge për të ndihmuar me migrimin e qendrave të të dhënave. Në veçanti, ai ishte i përfshirë në testimin e certifikimit dhe gatishmërisë. Përgjegjësitë e tij kërkonin që ai të koordinonte dhe të ndërtonte marrëdhënie midis ekipeve të zhvillimit të softuerit dhe ekipeve të operacioneve të serverit, bazës së të dhënave dhe rrjetit. Zhgënjimi i tij me mungesën e kohezionit dhe muret që ndajnë metodat e zhvillimit dhe funksionimit e lanë atë të hidhëruar. Dëshira e Desbois për t'u përmirësuar shpejt e çoi atë në veprim.
Në konferencën Agile të vitit 2008 në Toronto, Andrew Schaefer propozoi moderimin e një takimi jozyrtar të organizuar posaçërisht për të diskutuar temën "Infrastruktura e shkathët"Dhe vetëm një person erdhi për të diskutuar temën: Patrick DeBois. Diskutimi i tyre dhe shkëmbimi i ideve avancoi konceptin e administrimit të sistemeve Agile. Po atë vit, DeBois dhe Schaefer krijuan grupin mesatarisht të suksesshëm Agile Systems Administrator në Google.
2009: Rasti i bashkëpunimit ndërmjet Dev dhe Ops
Në konferencën O'Reilly Velocity, dy punonjës të Flickr, Zëvendës Presidenti i Lartë i Operacioneve Teknike John Allspaw dhe CTO Paul Hammond, dhanë prezantimin tashmë të famshëm "10 dislokime në ditë: Bashkëpunimi i Dev dhe Ops në Flickr".
Prezantimi ishte një dramë, me Allspaw dhe Hammond që rikrijuan ndërveprimet komplekse midis përfaqësuesve të Zhvillimit dhe Operacioneve gjatë procesit të vendosjes së softuerit, i kompletuar me gishta dhe akuza përgjatë vijave të "Nuk është kodi im, janë të gjithë kompjuterët tuaj!" Prezantimi i tyre konfirmoi se e vetmja mundësi e arsyeshme është që aktivitetet e zhvillimit dhe vendosjes së softuerit të jenë të qetë, transparente dhe plotësisht të integruara. Me kalimin e kohës, ky prezantim u bë legjendar dhe tani shihet historikisht si një moment historik kur industria e IT-së filloi të kërkonte metodologjinë e njohur sot si DevOps.
2010: DevOps në Shtetet e Bashkuara të Amerikës
Me një ndjekës në rritje, konferenca DevOpsDays u mbajt për herë të parë në Shtetet e Bashkuara në Mountain View, Kaliforni, menjëherë pas konferencës vjetore të Velocity. Shpejt përpara në 2018, dhe janë planifikuar më shumë se 30 konferenca DevOpsDays, duke përfshirë dhjetëra në Shtetet e Bashkuara.
2013: Projekti "Phoenix"
Për shumë prej nesh, një moment tjetër i rëndësishëm në historinë e DevOps ishte botimi i librit “The Phoenix Project” nga Gene Kim, Kevin Behr dhe George Safford. Ky roman tregon historinë e një menaxheri IT që gjendet në një situatë të dëshpëruar: ai ka për detyrë të shpëtojë një projekt kritik të tregtisë elektronike që ka shkuar keq. Mentori misterioz i menaxherit - një anëtar i bordit të drejtorëve i cili është i apasionuar pas metodave të prodhimit të ligët - i sugjeron personazhit kryesor mënyra të reja për të menduar për IT dhe zhvillimin e aplikacioneve, duke parashikuar konceptin e DevOps. Meqë ra fjala, "Projekti Phoenix" na frymëzoi të shkruanim librin "Outsource or other..." rreth një historie të ngjashme biznesi në të cilën një VP i softuerit përdor DevOps gjatë zhvillimit të një produkti të ri të madh të jashtëm.
DevOps për të ardhmen
Vlen të përshkruhet DevOps si një udhëtim, ose ndoshta një aspiratë, në vend të një destinacioni përfundimtar. DevOps, si prodhimi i dobët, përpiqet për përmirësim të vazhdueshëm, rritje të produktivitetit dhe efikasitetit, madje edhe vendosje të vazhdueshme. Mjetet e automatizuara për të mbështetur DevOps vazhdojnë të zhvillohen.
Është arritur shumë që nga fillimi i DevOps në dekadën e fundit, dhe ne presim të shohim edhe më shumë në 2018 dhe më tej.
Burimi: www.habr.com