„DevOps“ pagrindai ir koncepcijos

Šiame įraše aptarsime pagrindus, koncepcijas ir praktiką, kurios yra būtinos visiems dirbantiems „DevOps“ aplinkoje.

Mes apimsime šiuos dalykus:

• Kultūra - „Dev“ ir „Ops“ bendradarbiavimo kultūra
• Praktikos - Praktika, palaikanti „DevOps“ kultūros tikslus
• Įrankiai - įrankiai, padedantys įgyvendinti „DevOps“ praktiką
• Debesuota - Glaudus „DevOps“ ir debesies ryšys

Kas yra „DevOps“

DevOps = Dev (plėtra) + Ops (operacijos)

Šis „Wikipedia“ apibrėžimas yra geras atspirties taškas:

„DevOps“ yra programinės įrangos inžinerijos kultūra ir praktika, kuria siekiama suvienyti programinės įrangos kūrimą (Dev) ir programinės įrangos veikimą (Ops) ... „DevOps“ siekia trumpesnių kūrimo ciklų, didesnio diegimo dažnio, patikimesnių leidimų, glaudžiai derindamasis su verslo tikslais. “

„DevOps Is“

• „DevOps“ pirmiausia yra kūrėjų ir operacijų žmonių bendradarbiavimo kultūra
• Ši kultūra sukūrė praktikų rinkinį
• „DevOps“ yra darbo būdas
• „DevOps“ yra praktikų judėjimas, skirtas praktikams

„DevOps“ nėra

• „DevOps“ NĖRA įrankių rinkinys, tačiau įrankiai yra būtini sėkmei „DevOps“
• „DevOps“ NĖRA standartas
• „DevOps“ NĖRA produktas
• „DevOps“ NĖRA pareigos

„DevOps“ kultūra

„DevOps“ kultūra yra apie bendradarbiavimas tarp Dev ir Ops. Tradiciškai jiedu dirbo atskirai ir turėjo skirtingi ir prieštaraujantis tikslus.

Pagal DevOps kultūrą, Dev ir Ops dirba kartu ir dalijasi tas pats tikslas . Tai reiškia, kad „devs“ rūpinasi stabilumu, taip pat greičiu, o „ops“ - greičiu ir stabilumu.

Tradiciniai kūrėjų ir inžinierių vaidmenys tampa neryškūs naudojant „DevOps“.

Užuot „mėtę kodą per sieną“, „dev“ ir „ops“ kartu kuria ir naudoja įrankius bei procesus, kurie palaiko greitį ir stabilumą.

Su „DevOps“:

• „Dev“ ir „Ops“ žaidžia toje pačioje komandoje
• 
  

  „Dev“ ir „Ops“ turi tuos pačius tikslus

  
  
  
  
  • Greitas laikas į rinką (TTM)
  
  
  • Nedaug gamybos gedimų
  
  
  • Skubus atsigavimas po nesėkmių
  
  

Tradiciniai silosai

Kas buvo blogai tradiciniuose silosuose?

Pagal tradicinius silosus:

• Devai parašo kodą
• „Mesk per sieną“ QA
• Kodas pastebi pirmyn ir atgal tarp „Dev“ ir „QA“, nes QA aptinka problemas ir „Devs“ jas išsprendžia
• Galiausiai jis yra paruoštas gamybai

• QA / Dev „išmeta kodą per sieną“ Operacijoms
• Jei iškyla problema, Opsas ją išmeta atgal per sieną į Devą
• Kiekvienos grupės domenas yra „juodoji dėžutė“ kitoms grupėms
• Opsas pasakytų: „Mūsų sistemos yra puikios; tai tavo kodas! “
• Devas pasakytų: „Bet kodas veikia mano mašinoje!“

Toks darbo būdas sukelia daug pirštų rodymo - Ops yra juoda dėžutė, Devai iš tikrųjų jais nepasitiki, o Ops nelabai pasitiki.

„Dev“ ir „Ops“ turi skirtingus prioritetus - „Ops“ mano, kad „Devs“ pažeidžia stabilumą, o „Devs“ mano, kad operacijos yra kliūtis pristatyti savo kodą.

Net jei jie NORI dirbti kartu - „Dev“ yra matuojamas pateikiant funkcijas, o tai reiškia, kad diegiami pakeitimai, o „Ops“ - pagal veikimo laiką, tačiau pokyčiai kenkia stabilumui.

Tradicinių silosų minusai

• „Juodosios dėžės“ rodo pirštais
• Ilgas procesas reiškia lėtą pristatymo laiką
• Automatikos trūkumas reiškia, kad tokie dalykai kaip komponavimas ir diegimas yra nenuoseklūs
• Norint nustatyti ir išspręsti problemas, reikia daug laiko

„Dev“ ir „Ops“ sujungimas („DevOps“)

Kaip „DevOps“ išsprendžia tradicines silosų problemas?

Pagal „DevOps“ modelį:

• „Devs“ rašo kodą
• Kodo įsipareigojimas suaktyvina automatinį kūrimą, integravimą ir bandymus
• QA gali iš karto patekti į tai
• Kai jis bus paruoštas, pradėkite automatinį diegimą į gamybą

• Kadangi viskas yra automatizuota, ją įdiegti yra daug lengviau, tuo pačiu išlaikant stabilumą
• Diegimas gali įvykti daug dažniau, todėl funkcijos greičiau patenka į klientų rankas
• Jei naujausias diegimas sugadina ką nors gamyboje, automatinis stebėjimas nedelsdamas praneša komandai
• Komanda atlieka grįžimą, įdiegdama ankstesnę darbinę versiją, greitai išspręsdama problemą
• Po valandos „Dev“ komanda gali įdiegti fiksuotą naujojo kodo versiją

„Dev“ ir „Ops“ kartu siekė prioriteto tiek pristatymo greičiui, tiek stabilumui.

Automatika paskatino nuoseklumą - kūrimas, testavimas ir diegimas kiekvieną kartą vyko taip pat, daug greičiau ir dažniau

Geras stebėjimas ir greitas diegimo procesas užtikrino, kad problemas galima išspręsti dar prieš vartotojams jas pastebint. Nepaisant to, kad dėl kodo pakeitimo kilo problema, vartotojai prastovų veikė nedaug arba jų visai nebuvo.

„DevOps“ nauda

• Technikos komandos yra laimingesnės, kai daro „DevOps“, nei būdamos po tradiciniais silosais
• Daugiau laiko diegiant naujoves ir mažiau laiko gesinant gaisrus
• „Devs“ ir „Ops“ turi tą patį tikslą, kuris yra pristatymo greitis ir stabili sistema.
• „DevOps“ darbo būdas suteikia klientams norimas funkcijas greitai ir patikimai.