Devops je zdaj pomemben v mnogih tehnoloških organizacijah zaradi dveh navidezno nasprotujočih si misij in kultur, ki se morata združiti:
- Agilne razvojne ekipe se hitro premikajo, da izpolnijo poslovne zahteve in uvedejo spremembe aplikacij.
- Operativne skupine si močno prizadevajo, da bi sistemi še naprej delovali, zagotovili varno računalniško okolje in upravljali računalniške vire.
Agile ekipe pogosto gledajo na operativne ekipe kot na počasne in toge, sistemski inženirji pa na agilne razvijalce kot na nepodporne operativnim potrebam in nepremišljene, kadar uvajanje aplikacij povzroči težave s proizvodnjo.
Gre za posploševanje, vendar imata disciplini pogosto različne motivacije, terminologijo in orodja - in ta neusklajenost lahko ustvari poslovna vprašanja. Na primer, ko se zagonska podjetja povečujejo, morajo razviti operativne postopke, da zagotovijo stabilnost, hkrati pa minimalno vplivajo na njihovo hitrost in gibčnost. Za velika podjetja morajo najti načine, kako hitreje dostaviti aplikacije, usmerjene k strankam, in izboljšave notranjega poteka dela, ne da bi ogrozili zanesljivost ali neupoštevanje.
Cilj Devops je reševanje teh konfliktov s kulturo, nizom operativnih načel in nastajajočim naborom najboljših praks, ki omogočajo hitro uvajanje aplikacij in njihovo stabilnost z manj konflikti in kompromisi. To v veliki meri dosežemo z zagotavljanjem praks, ki avtomatizirajo operativne korake in standardizirajo konfiguracije:
- Za razvojne skupine te prakse standardizirajo in avtomatizirajo korake od razvoja kode do testiranja, zaščite in izvajanja aplikacij v več okoljih.
- Pri operacijah prakse spodbujajo avtomatizacijo pri konfiguriranju in uvajanju infrastrukture, spremljanje na več domenah in hitrejše reševanje proizvodnih težav.
Devops prakse vključujejo:
- Nadzor različic in strategije razvejanja.
- Nenehna integracija in neprekinjena dobava (CI / CD) cevovodi.
- Vsebniki, ki standardizirajo in izolirajo okolja za izvajanje aplikacij.
- Infrastruktura kot koda (IAC), ki omogoča skriptiranje infrastrukturne plasti.
- Spremljanje cevovodov devops in zdravstvenega stanja delujočih aplikacij.
Devops se začne s praksami in orodji, ki se uporabljajo za izdajo programske opreme za izračun okolij z osnovnimi postopki, ki obstajajo že desetletja. Vključujejo nadzor nad različicami za upravljanje sprememb kode v skupini razvijalcev, razvejanje baze kode za podporo različnim razvojnim dejavnostim in izdaje programske opreme za označevanje različic, preden jih potisnejo v različna okolja.
Glavne razlike za ekipe devops so v tem, da je orodja lažje uporabljati in jih bolje integrirati z drugimi tehnologijami, ki avtomatizirajo izdelavo in uvajanje aplikacij. Obstajajo tudi bolj standardizirane strategije razvejanja in združevanja kod, ki jih je lažje upravljati s sodobnimi sistemi za nadzor različic.
Mnoge organizacije na primer uporabljajo Git (vključno z različicama GitHub in BitBucket) in druga orodja za nadzor različic, ki ponujajo aplikacije za več odjemalcev, API-je za integracijo in orodja ukazne vrstice za upravljanje pogostejših ali zapletenejših postopkov. Danes je večina razvijalcev pri svojih projektih uporabila vsaj eno tehnologijo za nadzor različic, zato izvajanje standardov ni tako težko kot nekoč.
Organizacije, ki uporabljajo ta orodja, lahko sprejmejo strategije razvejanja, kot je Gitflow, ki standardizirajo podružnice za proizvodnjo, testiranje in razvoj ter vzpostavijo postopke za razvoj novih funkcij ali proizvodnih popravkov. Te strategije razvejanja omogočajo skupinam, da sodelujejo pri različnih vrstah razvojnih potreb in uvedejo le kodo, ki je preizkušena in jo je mogoče namestiti v proizvodne veje. Skupine nato z označevanjem različic označijo vse različice izvorne kode in druge datoteke, ki so del izdaje programske opreme.
Večina organizacij, ki po izdaji produkcije potrebujejo podporo uporabnikov, in druge, ki že zgodaj razvijajo svoje prakse devops, pogosto sledijo tradicionalnim praksam upravljanja izdaj, ki podpirajo konstrukcije, kot so glavne in manjše izdaje. Prefinjenejše ekipe, ki razvijajo aplikacije, ki potrebujejo manj uporabniške podpore, lahko vadijo neprekinjeno uvajanje, kadar obstaja avtomatizacija, ki nenehno integrira in prinaša spremembe kode v produkcijska okolja.
Da bi omogočili pogostejše izdaje, skupine poskušajo avtomatizirati korake od preverjanja kode do dostave popolnoma preizkušenih aplikacij v ciljna računalniška okolja. Neprekinjena integracija (CI) je avtomatizacija za izgradnjo in integracijo vseh komponent programske opreme, tako da so v paketu, ki ga je mogoče uvesti. Orodja za nenehno uvajanje (CD) upravljajo spremenljivke, specifične za okolje, in avtomatizirajo potiskanje aplikacij v razvojna, testna, proizvodna in druga računalniška okolja. Ta orodja skupaj tvorijo cevovod CI / CD.
Da bi bil CI / CD učinkovit postopek avtomatizacije, je treba v teku izvajati neprekinjeno preskušanje, da nova koda ne bo povzročala napak in drugih težav. Preizkusi enot, ki se izvajajo v cevovodu za neprekinjeno integracijo, zagotavljajo, da predana koda ne krši obstoječih preskusov enote. V koraku integracije lahko izvedemo tudi druge teste, ki iščejo varnostna vprašanja na ravni kode in strukturo kode. Avtomatizirana funkcionalnost in zmogljivost, ki zahtevata izvajalna okolja, sta pogosto avtomatizirana kot del cevovodov za neprekinjeno dostavo.
Ta avtomatizacija spodbuja številne koristne spremembe vedenja in prakse, ki skupinam omogočajo pogostejše in varnejše spremembe. Ekipe poganjajo pogostejše prijave in preizkušanje kode, kar omogoča hitrejše iskanje in odpravljanje napak. Postopki ročnega uvajanja so nagnjeni k napakam, kar avtomatizacija v veliki meri odpravi. Avtomatizacija zavzema tudi večino stroškov, saj uporabnikom omogoča nove zmogljivosti, kar omogoča skupinam pogostejšo uporabo.
Če CI / CD omogoča avtomatizacijo dostave aplikacij, potem so vsebniki embalaža delovnega okolja aplikacije. Razvijalci lahko določijo operacijski sistem, zahteve za aplikacije in zahteve za konfiguracijo kot vsebnik za zagon aplikacij v izolirani plasti, ki si deli operacijski sistem gostitelja. Docker in Kubernetes sta zabojniški tehnologiji, ki razvijalcem pomagata na dosleden način opredeliti svoja aplikacijska okolja.
S cevovodi CI / CD za integracijo in uvajanje kode ter s standardiziranimi vsebniki, ki izolirajo računalniške potrebe vsake aplikacije, imajo razvijalci orodja za izdelavo aplikacijskih storitev brez veliko dodatnih stroškov. Nato imajo razvojne skupine večje možnosti za prenos poslovnih zahtev v mikro storitve, ki jih je mogoče razviti, prilagoditi in izkoristiti za več poslovnih potreb.
Ker avtomatizacija integracije in dostave kode ter posodabljanje aplikacij spodbujajo dostavo aplikacij, naslednje prakse devops pomagajo avtomatizirati in standardizirati infrastrukturo in storitve v oblaku.
Avtomatizacija in upravljanje infrastrukture je bilo včasih težko. Ko je bila arhitektura izbrana, so operativni inženirji odšli na različne komponente infrastrukture, da bi jih zgradili in konfigurirali v skladu z zahtevami. Orodja za konfiguracijo in upravljanje sredstev, ki se uporabljajo za zajem teh arhitektur, so zahtevala kombinacijo avtomatiziranih in ročnih korakov, pogosto pa so bila zastarela ali so manjkale kritične informacije. Računalniška okolja so bila tudi toga in čeprav je bilo nekaj orodij za avtomatizacijo okolja za skaliranje, so bila pogosto izolirana do določene vrste infrastrukture, zahtevala so drugačna znanja za izvajanje avtomatizacije in so imela dostop samo do podnabora operativnih podatkov, da bi ugotovili, ali in kako za merjenje.
Današnja oblačna okolja ponujajo uporabniške vmesnike, ki inženirjem poenostavljajo delo. Inženirji lahko s temi orodji vzpostavijo navidezna zasebna omrežja, konfigurirajo varnostne skupine in nato zaženejo računanje, shranjevanje in druge potrebne storitve.
Toda ekipe devopsa naredijo ta korak naprej. Namesto da bi uporabili spletne vmesnike in ročno konfigurirali računalniške vire, postopek avtomatizirajo s kodo. Orodja za infrastrukturo kot kodo (IaC) omogočajo operativnim inženirjem skriptiranje in avtomatizacijo nastavitve in upravljanja infrastrukture. V te skripte je mogoče vdelati tudi konfiguracije, ki omogočajo spreminjanje okolij navzgor in navzdol. Chef, Puppet, Ansible in Salt so štiri konkurenčne tehnologije, ki pomagajo izvajati operativne skupine za izvajanje IaC.
Proizvodni postopek je tako dober kot zmožnost spremljanja, opozarjanja in okrevanja po težavah. Enako velja za spremljanje devopsov in uporabniško izkušnjo izvajanja aplikacij in storitev. Ker organizacije vlagajo v avtomatizacijo, zabojnike, standardizacijo in uvajanje aplikacij, je vzporedna naložba v spremljanje najboljša praksa.
Pomislite na spremljanje na več ravneh. Na najnižji ravni je spremljanje infrastrukture, ki omogoča prepoznavanje in odzive, kadar računalniški viri niso zdravi ali slabo delujejo. Oblačna okolja danes ponujajo zmogljivosti za spremljanje, opozarjanje in uporabo elastičnih oblačnih zmogljivosti za odzivanje na infrastrukturna vprašanja.
Naslednja plast je sestavljena iz orodij za spremljanje in zajemanje meritev okoli avtomatizacije devops. Ta orodja postajajo bolj kritična, ko se število razvijalcev in storitev, ki jih je mogoče uvesti, poveča. Ta orodja zagotavljajo opozorila ob neuspešni gradnji in orodja za revizijo, ki pomagajo diagnosticirati težave.
Nenazadnje obstajajo orodja, ki spremljajo čas delovanja, delovanje in druge meritve izvajanja aplikacije. Ta orodja za spremljanje pogosto preizkušajo API-je in izvajajo tudi celotne teste brskalnikov na posameznih končnih točkah ali transakcijah v več korakih. Ti monitorji so prva obramba, ki opozarja ekipe devops, kadar API-ji ali aplikacije delujejo zunaj sprejemljive ravni storitev.
Obstaja veliko praks devopsa in vsi vzamejo čas, da dozorijo in se integrirajo. Za njihovo izvajanje ni predpisanega zaporedja ali trdih priporočil, v koliko avtomatizacije vlagati.
Kljub temu bi si morale organizacije najprej prizadevati za uskladitev kulture in miselnosti z načeli devops, nato pa prepoznati, katere prakse najbolje ustrezajo poslovnim potrebam. Na primer, organizacije, ki že imajo slabo zmogljivost aplikacij, se lahko najprej odločijo za izvajanje nadzora, da bodo hitreje rešile težave in lažje ugotovile vzroke. Druge organizacije, ki začenjajo migracije v oblaku, se lahko odločijo, da bodo infrastrukturo uvedle kot kodo, tiste, ki vzpostavljajo standardne arhitekture za razvoj aplikacij, pa lahko vlagajo v cevovode CI / CD.
Tehnologi bi morali imeti v mislih, da pri uvajanju avtomatizacije obstajajo stroški in da vsaka organizacija ne zahteva nenehnega uvajanja. Najboljša praksa je, da najprej poskrbite za poslovne potrebe in avtomatizacijo devops prilagodite področjem z veliko ponavljanja, kjer so ročni napori nagnjeni k napakam.
