„Devops“ dabar yra svarbus daugelyje technologijų organizacijų dėl dviejų, atrodo, priešingų misijų ir kultūrų, kurios turi susiburti:
- Vikrios kūrėjų komandos greitai juda, kad atitiktų verslo reikalavimus ir įgyvendintų programų pakeitimus.
- Operatyvinės komandos stengiasi, kad sistemos veiktų, būtų užtikrinta saugi skaičiavimo aplinka ir valdomi skaičiavimo ištekliai.
Judrios komandos dažnai laiko operatyvines komandas lėtomis ir nelanksčiomis, o sistemos inžinieriai - judrius kūrėjus laiko operacinių poreikių nepalaikančiais ir neapgalvotais, kai programų diegimas sukelia gamybos problemų.
Tai yra apibendrinimai, tačiau šios dvi disciplinos dažnai turi skirtingą motyvaciją, terminologiją ir įrankius - ir šis nesutapimas gali sukelti verslo problemų. Pavyzdžiui, didėjant startuoliams, jie turi parengti veiklos procedūras, kad būtų užtikrintas stabilumas, o minimalus poveikis jų vystymosi greičiui ir judrumui. Didelėms įmonėms jos turi rasti būdų, kaip greičiau pritaikyti klientui skirtas programas ir vidinius darbo eigos patobulinimus, nepakenkiant patikimumui ir neatitinkant reikalavimų.
„Devops“ siekia išspręsti šiuos konfliktus pasitelkdama kultūrą, veikimo principų rinkinį ir atsirandantį geriausios praktikos rinkinį, leidžiantį greitai įdiegti programas ir stabiliai jas valdyti mažiau konfliktų ir kompromisų. Tai daugiausia daroma teikiant praktiką, kuri automatizuoja veiklos veiksmus ir standartizuoja konfigūracijas:
- Kūrėjų komandoms ši praktika standartizuoja ir automatizuoja veiksmus nuo kodo kūrimo iki programų testavimo, apsaugos ir vykdymo keliose aplinkose.
- Vykdant operacijas, praktika skatina automatizuoti konfigūruojant ir diegiant infrastruktūrą, stebint keletą sričių ir leidžiant greičiau išspręsti gamybos problemas.
Devops praktika apima:
- Versijų valdymo ir šakojimo strategijos.
- Nuolatinio integravimo ir nepertraukiamo tiekimo (CI / CD) vamzdynai.
- Konteineriai, kurie standartizuoja ir izoliuoja programų vykdymo laiką.
- „Infrastructure as code“ (IAC), leidžiantis užrašyti infrastruktūros sluoksnį.
- „Devops“ vamzdynų ir veikiančių programų būklės stebėjimas.
„Devops“ prasideda nuo praktikos ir įrankių, naudojamų programinei įrangai išleisti, kad būtų galima apskaičiuoti aplinką, naudojant pagrindines procedūras, kurios egzistuoja dešimtmečius. Jie apima versijų valdymą, skirtą valdyti kodo pakeitimus visoje kūrėjų komandoje, kodų šakojimą, kad būtų palaikomos skirtingos kūrimo veiklos, ir versijų žymėjimą programinės įrangos leidimus, prieš juos nukreipiant į skirtingas aplinkas.
Pagrindiniai „devops“ komandos skirtumai yra tai, kad įrankius lengviau naudoti ir geriau integruoti su kitomis technologijomis, kurios automatizuoja programų kūrimą ir diegimą. Taip pat yra labiau standartizuotų šakų ir kodų sujungimo strategijų, kurias lengviau valdyti naudojant šiuolaikines versijų valdymo sistemas.
Pavyzdžiui, daugelis organizacijų naudoja „Git“ (įskaitant „GitHub“ ir „BitBucket“ versijas) ir kitus versijų valdymo įrankius, kurie siūlo kelias klientų programas, integravimo API ir komandinės eilutės įrankius, kad valdytų dažnesnes ar sudėtingesnes procedūras. Šiandien dauguma kūrėjų savo projektuose naudojo bent vieną versijų valdymo technologiją, todėl įgyvendinti standartus nėra taip sunku, kaip anksčiau.
Organizacijos, naudojančios šiuos įrankius, gali taikyti tokias šakų strategijas kaip „Gitflow“, kurios standartizuoja gamybos, testavimo ir kūrimo šakas bei nustato naujų funkcijų ar gamybos pataisų kūrimo procedūras. Šios išsišakojimo strategijos leidžia komandoms bendradarbiauti, atsižvelgiant į įvairius plėtros poreikius, ir įveda tik patikrintą ir diegiamą kodą gamybos šakose. Tada komandos naudoja versijų žymėjimą, kad pažymėtų visas šaltinio kodo versijas ir kitus failus, kurie yra programinės įrangos leidimo dalis.
Dauguma organizacijų, kurioms reikia vartotojo palaikymo po gamybos leidimų, ir kitos, kurios dar anksti kuria savo „devops“ praktiką, dažnai vadovaujasi tradicine leidimų valdymo praktika, palaikančia tokias konstrukcijas kaip pagrindiniai ir smulkesni leidimai. Įmantresnės komandos, kuriančios programas, kurioms reikia mažiau vartotojo palaikymo, gali praktikuoti nuolatinį diegimą, kai yra automatika, kuri nuolat integruoja ir pateikia kodo pakeitimus į gamybos aplinką.
Norėdami įgalinti dažnesnius leidimus, komandos siekia automatizuoti veiksmus nuo kodo patikrinimo iki visiškai patikrintų programų pateikimo tikslinėms kompiuterinėms aplinkoms. Nuolatinė integracija (CI) - tai automatika, skirta kurti ir integruoti visus programinės įrangos komponentus taip, kad jie būtų diegiamame pakete. Nuolatinio diegimo (CD) įrankiai valdo specifinius aplinkos kintamuosius ir automatizuoja programų perkėlimą į kūrimo, bandymo, gamybos ir kitas skaičiavimo aplinkas. Šie įrankiai kartu sudaro CI / CD vamzdyną.
Kad CI / CD būtų efektyvus automatizavimo procesas, turi būti vykdomas nuolatinis bandymas, siekiant užtikrinti, kad naujas kodas nekeltų defektų ir kitų problemų. Nuolatinės integracijos procese vykdomi vienetų bandymai užtikrina, kad priskirtas kodas nepažeidžia jokių esamų vienetų testų. Kiti bandymai, ieškantys kodo lygio saugos problemų ir kodo struktūros, taip pat gali būti įgyvendinami integruojant. Automatinis funkcionalumas ir našumas, reikalaujantys vykdymo laiko aplinkos, dažnai yra automatizuojami kaip nuolatinio tiekimo vamzdynų dalis.
Ši automatika skatina daug naudingų elgsenos ir praktikos pokyčių, kurie komandoms leidžia dažniau ir saugiau atlikti pakeitimus. Tai skatina komandas dažniau tikrinti ir tikrinti kodą, o tai leidžia greičiau rasti ir pašalinti defektus. Neautomatinės diegimo procedūros yra linkusios į klaidas, kurias automatika iš esmės pašalina. Automatika taip pat užima didžiąją dalį pridėjus naujų galimybių vartotojams, leidžiant komandoms dislokuotis dažniau.
Jei CI / CD teikia automatiką pristatyti programas, konteineriai yra programos darbo aplinkos pakuotė. Kūrėjai gali nurodyti operacinę sistemą, programų reikalavimus ir konfigūracijos reikalavimus kaip talpyklą, skirtą programoms paleisti izoliuotame sluoksnyje, dalijantis pagrindinio kompiuterio operacine sistema. „Docker“ ir „Kubernetes“ yra talpyklų technologijos, padedančios kūrėjams nuosekliai apibrėžti savo programų aplinką.
Naudodami CI / CD vamzdynus, kad būtų galima integruoti ir įdiegti kodą, ir su standartizuotais konteineriais, kurie izoliuoja kiekvienos programos skaičiavimo poreikius, kūrėjai turi įrankius gaminti programų paslaugas be didelių išlaidų. Kūrėjų komandos turi didesnes galimybes verslo reikalavimus paversti mikroservomis, kurias galima pritaikyti, pritaikyti ir pritaikyti įvairiems verslo poreikiams.
Kadangi kodų integravimo ir pristatymo automatizavimas bei programų kaupimas konteineriuose skatina programų pristatymą, kita „devops“ praktika padeda automatizuoti ir standartizuoti infrastruktūrą ir debesijos paslaugas.
Anksčiau buvo sunku automatizuoti ir valdyti infrastruktūrą. Pasirinkus architektūrą, operatyvūs inžinieriai nuėjo prie įvairių infrastruktūros komponentų, kad juos sukonstruotų ir sukonfigūruotų pagal reikalavimus. Konfigūracijos ir turto valdymo įrankiai, naudojami šioms architektūroms užfiksuoti, reikalavo automatinių ir rankinių veiksmų derinio ir dažnai buvo pasenę arba trūko svarbios informacijos. Skaičiavimo aplinka taip pat buvo nelanksti ir, nors buvo keletas įrankių, leidžiančių automatizuoti mastelio aplinką, jie dažnai buvo izoliuoti nuo konkretaus tipo infrastruktūros, automatizavimui įgyvendinti reikalingi skirtingi įgūdžiai ir turėjo prieigą tik prie operacinių duomenų pogrupio, kad nustatytų, ar ir kaip masteliu.
Šiandienos debesų aplinka siūlo vartotojo sąsajas, kurios supaprastina darbą inžinieriams. Inžinieriai gali naudoti šiuos įrankius norėdami nustatyti virtualius privačius tinklus, konfigūruoti saugos grupes ir paleisti skaičiavimo, saugojimo ir kitas reikalingas paslaugas.
Tačiau „devops“ komandos žengia šį žingsnį toliau. Užuot naudojęsi interneto sąsajomis ir rankiniu būdu konfigūruodami skaičiavimo išteklius, jie automatizuoja procesą naudodami kodą. „Infrastructure as code“ (IaC) įrankiai leidžia operatyviems inžinieriams kurti scenarijus ir automatizuoti infrastruktūros nustatymą ir valdymą. Konfigūracijos, leidžiančios didinti ir mažinti aplinką, taip pat gali būti įtrauktos į šiuos scenarijus. „Chef“, „Lėlė“, „Ansible“ ir „Druska“ yra keturios konkuruojančios technologijos, padedančios įgyvendinti operatyvines komandas įgyvendinant IR.
Gamybos procesas yra toks pat geras, kaip galimybė stebėti, perspėti ir atsigauti po problemų. Tas pats pasakytina ir apie stebėjimą „Devops“ ir vartotojų patirtį naudojant programas ir paslaugas. Organizacijoms investuojant į automatizavimą, konteinerių sudarymą, standartizavimą ir diegimą, lygiagreti investicija į stebėseną yra geriausia praktika.
Pagalvokite apie stebėjimą keliais lygmenimis. Žemiausias lygis yra infrastruktūros stebėjimas, leidžiantis atpažinti ir atsakyti, kai skaičiavimo ištekliai nėra tinkami arba veikia nepakankamai. Debesų aplinka šiandien siūlo galimybes stebėti, įspėti ir naudoti elastingas debesies galimybes, kad būtų galima išspręsti infrastruktūros problemas.
Kitą sluoksnį sudaro įrankiai, skirti stebėti ir fiksuoti metriką, susijusią su „devops“ automatika. Šios priemonės tampa vis svarbesnės, nes didėja kūrėjų ir diegiamų paslaugų skaičius. Šie įrankiai pateikia įspėjimus, kai komponavimas nepavyksta, ir audito įrankiai, kurie padeda diagnozuoti problemas.
Galiausiai yra įrankių, kurie stebi programos veikimo laiką, našumą ir kitą vykdymo laiko metriką. Šie stebėjimo įrankiai dažnai išbando API ir taip pat atlieka visus naršyklės bandymus, atlikdami atskirus galinius taškus arba daugiapakopes operacijas. Šie monitoriai yra tiesioginė gynyba, skirta įspėti iškylančiųjų komandas, kai API ar programos veikia už priimtino paslaugų lygio ribų.
Yra daug devopų praktikų, ir joms visoms reikia laiko, kad subręstų ir integruotųsi. Nėra nustatytos jų įgyvendinimo sekos ar griežtų rekomendacijų, į kiek automatikos investuoti.
Vis dėlto organizacijos pirmiausia turėtų siekti suderinti kultūrą ir mąstyseną su „devops“ principais ir tada pripažinti, kokia praktika geriausiai atitinka verslo poreikius. Pvz., Organizacijos, kurios jau patiria prastą programų našumą, gali nuspręsti pirmiausia įgyvendinti stebėjimą, kad būtų lengviau išspręsti problemas ir lengviau nustatyti pagrindines priežastis. Kitos debesijos perkėlimą pradedančios organizacijos gali pasirinkti diegti infrastruktūrą kaip kodą, o kuriančios standartines programų kūrimo architektūras, gali investuoti į CI / CD vamzdynus.
Technologai turėtų nepamiršti, kad automatizavimas kainuoja brangiai ir kad ne kiekvienai organizacijai reikia nuolatinio diegimo. Geriausia praktika yra įsitikinti, kad pirmiausia tenkinami verslo poreikiai, ir suderinti automatizavimą su tomis sritimis, kuriose pasikartojama daug kartų, kai rankomis stengiamasi padaryti klaidas.
