„Devops“ gali būti vienas iš pavojingiausių programinės įrangos kūrimo terminų, tačiau dauguma iš mūsų sutinka, kad penkios veiklos daro „devops“ tai, kas yra: nuolatinė integracija, nuolatinis pristatymas, debesų infrastruktūra, bandymų automatika ir konfigūracijos valdymas. Jei atliksite šiuos penkis dalykus, atliksite „devops“. Aišku, kad visi penki yra svarbūs norint teisingai nuspręsti, tačiau pernelyg lengva suklysti. Visų pirma, nuolatinė integracija ir nepertraukiamas pristatymas (CI / CD) gali būti sunkiausias devopų žingsnis įvaldyti.
Nuolatinė integracija (PI) yra procesas, kurio metu kūrėjai ir testuotojai kartu patvirtina naują kodą. Tradiciškai kūrėjai rašė kodą ir integravo jį kartą per mėnesį testavimui. Tai buvo neefektyvu - klaida prieš keturias savaites prieš kodą galėjo priversti kūrėjus peržiūrėti prieš savaitę parašytą kodą. Norėdami įveikti šią problemą, PI priklauso nuo automatizavimo, kad nuolat integruotų ir testuotų kodą. „Scrum“ komandos, naudojančios KI, bent jau kasdien priskiria kodą, o dauguma jų - kodą kiekvienam įvestam pakeitimui.
Nuolatinis pristatymas (CD) yra procesas, kuriame nuolat kuriami išleidžiami artefaktai. Kai kurios įmonės vartotojams išleidžia vieną ar net kelis kartus per dieną, o kitos dėl rinkos priežasčių išleidžia programinę įrangą lėčiau. Bet kokiu atveju, gebėjimas paleisti yra nuolat tikrinamas. Nuolatinis dislokavimas yra įmanoma dėl debesų aplinkos. Serveriai yra nustatyti taip, kad juos galėtumėte įdiegti gamyboje neišjungdami ir rankiniu būdu neatnaujindami serverių.
Taigi CI / CD yra nuolatinio naujojo kodo kūrimo, testavimo ir pristatymo procesas. Kai kurios kompanijos, tokios kaip „Facebook“ ir „Netflix“, naudoja CI / CD, kad išleistų 10 ar daugiau leidimų per savaitę. Kitos kompanijos stengiasi pasiekti tą tempą, nes pasiduoda vienai ar daugiau iš penkių spąstų, kuriuos aptarsiu toliau.
CI / CD spąstai Nr. 1: pirmiausia neteisingų procesų automatizavimas
Šie spąstai yra linkę smogti organizacijoms, kurios nuo krioklio plėtros pereina prie iškastinių. Naujos organizacijos turi pranašumą diegti CI / CD nuo nulio. Esamos įmonės turi palaipsniui pereiti nuo rankinio iki labai automatizuoto kūrimo. Visiškas perėjimas gali užtrukti keletą mėnesių, o tai reiškia, kad turėsite kartoti, kaip pritaikote CI / CD.
Kai paklausite: „Ar tai reikia dabar automatizuoti?“ vykdykite šį kontrolinį sąrašą:
- Kaip dažnai procesas ar scenarijus kartojasi?
- Kaip ilgai trunka procesas?
- Kokie žmonės ir priklausomybė nuo išteklių yra susiję su procesu? Ar dėl jų vėluoja CI / CD?
- Ar procesas yra linkęs į klaidas, jei jis nėra automatizuotas?
- Kaip skubiai reikia procesą automatizuoti?
Naudodamiesi šiuo kontroliniu sąrašu, galite nustatyti prioritetus CI / CD diegimo veiksmams. Visų pirma, automatizuokite kodo sudarymo procesą. Idealiu atveju, jūs integruosite kodą kelis kartus per dieną (1). Rankiniu būdu procesas trunka nuo kelių minučių iki poros valandų (2). Tai sustabdo išvestį, kol kompiliatorius baigs užduotį (3). Jis taip pat yra linkęs į žmogaus klaidas (4), ir kadangi CI / CD yra svajonė be automatinės integracijos, tai yra skubu (5).
Mes galime paleisti tą patį bandymų kontrolinį sąrašą. Pereinant prie CI / CD, gali kilti klausimas: ar pirmiausia turėtume automatizuoti funkcinį testavimą ar vartotojo sąsajos testavimą? Abu jie bus kartojami bent kartą per dieną (1). Abi vidutinio dydžio programos gali trukti nuo dviejų iki trijų valandų (2). Bet jie apima daugybę priklausomybių (3). Automatizavus funkcinį testavimą, gali tekti ne taip dažnai atnaujinti automatikos scenarijų. Kita vertus, vartotojo sąsaja dažnai keičiasi, todėl reikia dažnai keisti scenarijų. Nors abu yra linkę į klaidas (4), prieš sąsajos testavimą turėtumėte teikti pirmenybę funkciniam testavimui, kad geriausiai išnaudotumėte savo išteklius (5).
Padarykime tai dar kartą su aplinkos nustatymo procesu. Šis scenarijus dažnai kartojamas tik tuo atveju, jei jūs samdote krizę ar patiriate sunkų nerimą (1). Tai gana daug laiko reikalaujantis procesas, kuris gali trukti kelias valandas, jei ne dienas (2). Nauji komandos nariai be aplinkos negali padaryti nieko naudingo, todėl akivaizdu, kad yra priklausomybė ir vėlavimas (3). Nepasakyčiau, kad procesas yra linkęs į klaidas (4), taigi ar jis vis dar skubus (5)? Aš linkstu į taip, bet vis tiek pirmiausia turėčiau prioritetą integracijai ir funkciniams testams.
Nėra tokio dalyko kaip pervertinimas. Jei turėtumėte neribotus išteklius, viską automatizuotumėte. Tai sakė, tu negali pasiekti visišką bandymų automatizavimą. Kartais galite suskaidyti užduotis į mažesnius segmentus ir automatizuoti pataisose. Kartais turėtumėte paprasčiausiai išsamiai dokumentuoti procesą ir atlikti jį rankiniu būdu.
CI / CD spąstai Nr. 2: painiojamas nuolatinis diegimas nuolatiniam pristatymui
Nuolatinis diegimas yra koncepcija, kad visi pakeitimai, atlikti kodų bazėje, bus iš karto pritaikyti gamybai, jei dujotiekio rezultatai bus sėkmingi. Tai kelia siaubą daugumai organizacijų, nes spartūs produkto pakeitimai gali atbaidyti vartotojus.
Įmonės mano, kad jei jos nepraktikuoja nuolatinio diegimo, nedaro kompaktinių diskų. Jie nesugeba atskirti nuolatinio diegimo ir nuolatinio pristatymo.
Nuolatinis pristatymas yra koncepcija, kad kiekvienas kodo pagrindo pakeitimas eina per dujotiekį iki taško, kuriame jis naudojamas neproduktyvioje aplinkoje. Komanda suranda ir išsprendžia problemas nedelsdama, ne vėliau, kai planuoja išleisti kodų bazę.
Kodo bazė visada yra tokios kokybės, kad ją būtų galima saugiai išleisti. Kada išleisti kodų bazę gamybai yra verslo sprendimas.
Nuolatinis diegimas kelia nerimą daugeliui organizacijų, o nuolatinis pristatymas jas rezonuoja. Nepertraukiamas pristatymas suteikia jiems galimybę kontroliuoti produkto pristatymą, funkcionalumą ir rizikos veiksnius. Yra laiko atlikti alfa testus, beta klientams, ankstyviems vartotojams ir pan.
CI / CD spąstai Nr. 3: prasmingų informacijos suvestinių ir metrikos trūkumas
Įgyvendindami CI / CD, tikrinimo komanda gali sukurti informacijos suvestinę, kol nariai nežino, ką jiems reikia stebėti. Todėl komanda patenka į logiško klaidumo auką: „Tai yra metrika, kurią turime, todėl jie turi būti svarbūs“. Verčiau atlikite laipsnišką vertinimą prieš tai projektuojant prietaisų skydelį.
Skirtingi IT organizacijos nariai ir net įvairūs komandos nariai turi skirtingus prioritetus. Pavyzdžiui, tinklo veikimo centre (NOC) esantys žmonės mėgsta raudonus, geltonus ir žalius indikatorius. Tokie šviesoforo prietaisų skydeliai suteikia galimybę NOC darbuotojams atskirti problemas neskaičius tankaus teksto ir neapmokestinant jų analitinių galimybių. Šviesoforai padeda šimtus serverių valdyti.
Jums taip pat gali kilti pagunda naudoti šviesoforo prietaisų skydelį CI / CD. Žalia, mes einame į teisingą kelią. Geltona, mes ne savo kelyje, bet turime planą tai išspręsti. Raudona, mes ne savo kelyje ir tikriausiai turime pakeisti savo tikslus.
Ta informacijos suvestinė tikriausiai yra naudinga „scrum“ meistrui, bet kaip yra su plėtros viceprezidentu ar CTO? Jei „scrum“ komandos laukia 350 valandų darbas dviejų savaičių sprintui ir jos 10 narių atskaitingi už 35 valandas, jie gautų atitinkamą skaičių istorijos taškų. Aukštesnei vadovybei gali būti mažiau įdomu istorijos taškų būsena ir įdomiau „sudegimo“ rodiklis: užduočių atlikimo greitis. Ar komandos nariai neša savo krovinius? Kaip greitai? Ar laikui bėgant jie tobulėja?
Deja, perdegimo rodikliai gali būti klaidinantys, jei įvairios suinteresuotosios šalys nesupranta grupės narių įprasto įpročio. Kai kurios komandos sudegina taškus anksti eidamos. Kiti laukia iki sprinto pabaigos, kad sudegintų atvirus taškus. Prietaisų skydelyje reikėtų į tai atsižvelgti.
Jei galite įvertinti, kokių duomenų nori visi, ir sukurti standartinį pasakojimą, ką tie duomenys reiškia, galite sukurti naudingą informacijos suvestinę. Bet neužgožk esmės dėl išvaizdos sąskaita. Paklauskite, kaip suinteresuotosios šalys nori, kad tai atrodytų. Ar grafikai, tekstas ar skaičiai būtų geriausi?
Tai yra aspektai, kuriuos reikia ištirti atliekant laipsnišką vertinimą. Jie iliustruoja, kaip sudėtinga sukurti naudingą CI / CD prietaisų skydelį ir visus pradžiuginti. Labai dažnai pats balsingiausias komandos narys užgrobia procesą, o kiti jaučiasi nusivylę, kad prietaisų skydelis atitinka tik vieno žmogaus pageidavimus. Klausykite visų.
CI / CD spąstai Nr. 4: trūksta nuolatinės integracijos ir nuolatinio pristatymo koordinavimo
Ši spąstai sugrąžina mus į bendrą sutarimų apibrėžimą, pagal kurį nuolatinė integracija ir nuolatinis pristatymas yra du skirtingi dalykai. PI tiekia Kompaktinis diskas. Tinkamo nuolatinio integravimo vamzdyno ir visiško nepertraukiamo pristatymo sistemos įgyvendinimas trunka keletą mėnesių ir reikalauja bendradarbiavimo. Kokybės užtikrinimas, „devops“ komanda, inžinieriai inžinieriai, „scrum“ meistrai - visi turi prisidėti. Bene sunkiausias CI / CD aspektas yra šis žmogiškasis faktorius, o ne koks nors techninis iššūkis, kurį aptarėme. Kaip negalite užprogramuoti sveikų dviejų žmonių santykių, negalite automatizuoti bendradarbiavimo ir bendravimo.
Norėdami įvertinti šį koordinavimo lygį, palyginkite savo PI / CD procesą su geriausiu versle. Tokios kompanijos kaip „Netflix“ gali užbaigti integravimą, testavimą ir pristatymą per dvi ar tris valandas. Jie sukūrė sistemą, kuri perduoda kodą iš rankų į rankas be apsisprendimo ir diskusijų. Ne, tai nėra 100 procentų automatizuota, nes tai neįmanoma naudojant dabartines technologijas.
CI / CD spąstai Nr. 5: subalansuoti nuolatinių integracijos darbų ir išteklių naudojimo dažnumą
Nuolatinės integracijos užduotys turėtų būti suaktyvintos atliekant kiekvieną kode įvestą pakeitimą. Sėkmingi darbai leidžia atlikti pokyčius, o nesėkmės juos atmeta. Tai skatina kūrėjus patikrinti mažesnius kodo gabalus, todėl per dieną sukuriama daugiau versijų. Tačiau nereikalingi nuolatinės integracijos darbai sunaudoja išteklius, o tai eikvoja laiką ir pinigus.
Kadangi šis procesas reikalauja daug išteklių (procesoriaus, energijos, laiko), programinę įrangą reikėtų suskaidyti į mažesnius komponentus, kad būtų sukurti greičiau veikiantys vamzdynai. Arba nuolatinės integracijos užduotys turėtų būti skirtos paketiniams registravimams, kurie pirmiausia išbandomi vietoje. Tikslas yra rasti pusiausvyrą tarp nuolatinių integracijos darbų atlikimo dažnumo ir išteklių panaudojimo.
Laikykite tikslą akyse
Įsigilinę į CI / CD spąstus - kartu su visa jo ezoterine terminologija - lengva pamesti akis kodėl tai svarbu. Galų gale CI / CD yra būtinas, nes jis atitinka verslo tikslus.
Technologijų vadovai žino, kad nuolatinė evoliucija, greiti pataisymai ir kokybiški rezultatai sukuria ir išlaiko klientus. Jie žino, kad nepavykęs leidimas pakviečia bliūdą į „App Store“ apžvalgas, o susigrąžinti aukštus atsiliepimus yra sunkiau nei juos išlaikyti. „Devops“ gali sukurti geresnę darbo patirtį jūsų komandai, tačiau ne todėl įmonės įdiegia „devops“.
Paprasčiau tariant, KI / CD spąstus verta peržiūrėti, nes kyla pavojus milijardams dolerių. Nors aš nerekomenduoju jums pridėti atsargų žymeklio ar „App Store“ peržiūros stebėjimo priemonės į savo CI / CD prietaisų skydelį, aš raginu jus tai žinoti. Daug kas priklauso nuo CI / CD smulkmenų.
Zubinas Irani yra visų paslaugų konsultavimo „cPrime“ įkūrėjas ir generalinis direktorius, kuris vykdo judrius pokyčius ir teikia judrius sprendimus daugiau nei 50 „Fortune 100“ firmų ir daugeliui didžiausių Silicio slėnio darbdavių.
Naujųjų technologijų forumas suteikia galimybę tyrinėti ir aptarti besiformuojančios įmonės technologijas beprecedentiame gylyje. Atranka yra subjektyvi, atsižvelgiant į mūsų pasirinktas technologijas, kurios, mūsų manymu, yra svarbios ir labiausiai domina skaitytojus. nepriima rinkodaros užtikrinimo priemonės paskelbimui ir pasilieka teisę redaguoti visą pateiktą turinį. Visus klausimus siųskite adresu [email protected].
