Devops var būt viens no visdrošākajiem programmatūras izstrādes terminiem, taču lielākā daļa no mums piekrīt, ka piecas darbības padara devops par to, kas tas ir: nepārtraukta integrācija, nepārtraukta piegāde, mākoņu infrastruktūra, testa automatizācija un konfigurācijas pārvaldība. Ja jūs darāt šīs piecas lietas, jūs darāt devops. Skaidrs, ka visi pieci ir svarīgi, lai kļūtu pareizi, bet pārāk viegli kļūdīties. Jo īpaši nepārtraukta integrācija un nepārtraukta piegāde (CI / CD) var būt visgrūtāk, kad devops pārvietojas.
Nepārtraukta integrācija (CI) ir process, kurā izstrādātāji un testētāji kopīgi apstiprina jauno kodu. Tradicionāli izstrādātāji uzrakstīja kodu un integrēja to reizi mēnesī testēšanai. Tas bija neefektīvi - kļūda kodā pirms četrām nedēļām var likt izstrādātājiem pārskatīt kodu, kas uzrakstīts pirms nedēļas. Lai pārvarētu šo problēmu, KI ir atkarīga no automatizācijas, lai nepārtraukti integrētu un pārbaudītu kodu. Scrum komandas, kas izmanto CI, vismaz katru dienu piešķir kodu, savukārt lielākā daļa no tām piešķir kodu visām ieviestajām izmaiņām.
Nepārtraukta piegāde (CD) ir process, kurā nepārtraukti tiek izveidoti atbrīvojami artefakti. Daži uzņēmumi izlaiž lietotājus vienu vai pat vairākas reizes dienā, bet citi programmatūru tirgū izlaiž lēnāk. Jebkurā gadījumā spēja atbrīvot tiek nepārtraukti pārbaudīta. Nepārtraukts izvietošana ir iespējams, pateicoties mākoņu vidēm. Serveri ir iestatīti tā, lai tos varētu izvietot ražošanā, neizslēdzot un manuāli neatjauninot serverus.
Tādējādi CI / CD ir nepārtraukta jauna koda izstrādes, testēšanas un piegādes process. Daži uzņēmumi, piemēram, Facebook un Netflix, izmanto CI / CD, lai pabeigtu 10 vai vairāk izlaidumus nedēļā. Citi uzņēmumi cīnās, lai sasniegtu šo tempu, jo viņi pakļaujas vienai vai vairākām no piecām kļūmēm, kuras es apspriedīšu tālāk.
CI / CD kļūda # 1: vispirms nepareizu procesu automatizēšana
Šis slazds mēdz pārspēt organizācijas, kas pāriet no ūdenskrituma attīstības uz devops. Jaunām organizācijām ir priekšrocība, ka CI / CD tiek ieviesti no jauna. Esošajiem uzņēmumiem ir pakāpeniski jāpārceļas no manuālas uz ļoti automatizētu attīstību. Pilnīga pāreja var ilgt vairākus mēnešus, kas nozīmē, ka jums ir jābūt atkārtotam, pieņemot CI / CD.
Kad jūs jautājat: "Vai tas tagad ir jā automatizē?" izlaist šo kontrolsarakstu:
- Cik bieži process vai scenārijs tiek atkārtots?
- Cik ilgs ir process?
- Kādi cilvēki un atkarība no resursiem ir iesaistīti procesā? Vai tie izraisa kavēšanos ar CI / CD?
- Vai process ir pakļauts kļūdām, ja tas nav automatizēts?
- Kāda ir steidzamība, lai procesu automatizētu?
Izmantojot šo kontrolsarakstu, jūs varat noteikt prioritāti KI / CD ieviešanas darbībām. Pirmkārt un galvenokārt, automatizējiet koda sastādīšanas procesu. Ideālā gadījumā jūs integrēsiet kodu vairākas reizes dienā (1). Manuāli process ilgst no dažām minūtēm līdz pāris stundām (2). Tas aptur izvadi, līdz kompilators pabeidz uzdevumu (3). Tas ir arī uzņēmīgs pret cilvēku kļūdām (4), un, tā kā CI / CD ir sapnis bez automatizētas integrācijas, tas ir steidzami (5).
Mēs varam palaist to pašu pārbaudes sarakstu testēšanai. Pārejot uz CI / CD, jūs varētu domāt: vai mums vispirms vajadzētu automatizēt funkcionālo testēšanu vai UI testēšanu? Abi tiks atkārtoti vismaz vienu reizi dienā (1). Abiem vidēja izmēra lietojumiem var paiet divas līdz trīs stundas (2). Bet tie ir saistīti ar vairākām atkarībām (3). Ja automatizējat funkcionālo testēšanu, iespējams, nebūs tik bieži jāatjaunina automatizācijas skripts. Turpretī lietotāja interfeiss bieži mainās, un tāpēc tas prasa biežas skriptu izmaiņas. Lai gan abos gadījumos ir iespējama kļūda (4), pirms lietotāja saskarnes testēšanas par prioritāti jāizvirza funkcionālā pārbaude, lai vislabāk izmantotu savus resursus (5).
Darīsim to vēl vienu reizi ar vides iestatīšanas procesu. Šis scenārijs tiek bieži atkārtots tikai tad, ja jūs pieņemat darbā uzdzīvi vai ja jums ir smags satraukums (1). Tas ir diezgan laikietilpīgs process, kas var ilgt vairākas stundas, ja ne dienas (2). Jaunie komandas locekļi bez vides nevar darīt neko noderīgu, tāpēc nepārprotami pastāv atkarība un kavēšanās (3). Es neteiktu, ka process ir pakļauts kļūdām (4), tāpēc vai tas joprojām ir steidzams (5)? Es sliecos uz “jā”, taču es tomēr vispirms liktu prioritāti integrācijai un funkcionālajai pārbaudei.
Nav tādas lietas kā pārvērtēšana. Ja jums būtu neierobežoti resursi, jūs automatizētu visu iespējamo. Tas teica, tu nevar panākt pilnīgu testa automatizāciju. Dažreiz jūs varat sadalīt uzdevumus mazākos segmentos un automatizēt ielāpus. Dažreiz jums vienkārši vajadzētu dokumentēt procesu detalizēti un izpildīt manuāli.
CI / CD kļūda # 2: sajaucot nepārtrauktu izvietošanu nepārtrauktai piegādei
Nepārtraukta izvietošana ir koncepcija, ka visas izmaiņas, kas veiktas kodu bāzē, gandrīz nekavējoties tiks izvietotas ražošanā, ja cauruļvada rezultāti būs veiksmīgi. Lielākajai daļai organizāciju tas ir biedējoši, jo straujas produktu izmaiņas var aizbaidīt lietotājus.
Uzņēmumi uzskata, ka, ja viņi nepraktizē nepārtrauktu izvietošanu, viņi nedara CD. Viņi nespēj nošķirt nepārtrauktu izvietošanu un nepārtrauktu piegādi.
Nepārtraukta piegāde ir jēdziens, ka visas izmaiņas koda bāzē iet cauri cauruļvadam līdz vietai, kurā tās tiek izvietotas neprodukcijas vidēs. Komanda atrod un risina problēmas nekavējoties, ne vēlāk, kad plāno atbrīvot kodu bāzi.
Kodu bāze vienmēr ir kvalitātes līmenī, kas ir droša izlaišanai. Kad atbrīvot kodu bāzi ražošanā ir biznesa lēmums.
Tā kā nepārtraukta izvietošana nemierina lielāko daļu organizāciju, nepārtraukta piegāde viņos atsaucas. Nepārtraukta piegāde ļauj viņiem kontrolēt produkta ieviešanu, funkcionalitāti un riska faktorus. Ir laiks alfa testēšanai, beta klientiem, agrīnajiem lietotājiem utt.
CI / CD kļūda # 3: jēgpilnu informācijas paneļu un metrikas trūkums
CI / CD ieviešanā izpētes komanda var izveidot informācijas paneli, pirms dalībnieki zina, kas viņiem jāizseko. Rezultātā komanda kļūst par loģiskas maldības upuri: "Tie ir rādītāji, kas mums ir, tāpēc tiem jābūt svarīgiem." Tā vietā veiciet pakāpenisku novērtēšanu pirms informācijas paneļa projektēšana.
Dažādiem IT organizācijas locekļiem un pat dažādiem grupas locekļiem ir atšķirīgas prioritātes. Piemēram, tīkla darbības centra (NOC) ļaudīm patīk sarkanie, dzeltenie un zaļie indikatori. Šādi luksofora paneļi ļauj NOC darbiniekiem atšķirt problēmas, nelasot blīvu tekstu un neapliekot ar nodokli viņu analītiskās spējas. Luksofori palīdz simtiem serveru padarīt vadāmus.
Jums varētu rasties kārdinājums izmantot luksofora informācijas paneli arī CI / CD. Zaļā, mēs esam uz pareizā ceļa. Dzeltenā krāsā, mēs esam ārpus sliežu ceļa, bet mums ir plāns to novērst. Sarkans, mēs esam ārpus ceļa un, visticamāk, ir jāmaina mērķi.
Šis informācijas panelis, iespējams, ir noderīgs skrāpju meistaram, bet kā ar attīstības VP vai CTO? Ja skrumpja komandai divu nedēļu sprintā ir 350 stundas darba un tās 10 dalībnieki ir atbildīgi par 35 stundām katrs, viņi saņemtu atbilstošu skaitu stāsta punktu. Augstākā vadība varētu būt mazāk ieinteresēta sižeta punktu statusā un interesantāka par “izdegšanas” līmeni: uzdevuma izpildes ātrumu. Vai komandas locekļi nes savas kravas? Cik ātri? Vai tie laika gaitā uzlabojas?
Diemžēl izdegšanas rādītāji varētu būt maldinoši, ja dažādas ieinteresētās puses nesaprot scrum komandas norunātos ieradumus. Dažas komandas dedzina punktus jau agri. Citi gaida līdz sprinta beigām, lai sadedzinātu atklātos punktus. Informācijas panelī tas jāņem vērā.
Ja jūs varat novērtēt, kādus datus visi vēlas, un izveidot standarta stāstījumu par to, ko šie dati nozīmē, varat izveidot noderīgu informācijas paneli. Bet nepieskarieties saturam uz izskata rēķina. Pajautājiet, kā ieinteresētās personas vēlas, lai tas izskatās. Vai diagrammas, teksts vai skaitļi būtu vislabākie?
Šie ir apsvērumi, kas jāizpēta progresīvā novērtējumā. Tie ilustrē, cik grūts ir izveidot noderīgu CI / CD informācijas paneli un padarīt visus laimīgus. Pārāk bieži visskaļākais komandas loceklis nolaupa procesu, un citi jūtas neapmierināti, ka informācijas panelis atbilst tikai vienas personas vēlmēm. Klausieties visus.
CI / CD kļūda # 4: koordinācijas trūkums starp nepārtrauktu integrāciju un nepārtrauktu piegādi
Šis trūkums mūs atgriež pie mūsu vienprātīgās devops definīcijas, kurā teikts, ka nepārtraukta integrācija un nepārtraukta piegāde ir divi dažādi elementi. CI plūsmas CD. Pienācīgas nepārtrauktas integrācijas cauruļvada un pilnīgas nepārtrauktas piegādes sistēmas ieviešana prasa mēnešus un prasa sadarbību. Kvalitātes nodrošināšana, devops komandai, inženieriem inženieriem, scrum meistariem - visiem ir jāpiedalās. Varbūt vissmagākais CI / CD aspekts ir šis cilvēciskais faktors, nevis jebkurš tehnisks izaicinājums, ko mēs esam apsprieduši. Tāpat kā jūs nevarat ieprogrammēt veselīgas attiecības starp diviem cilvēkiem, jūs nevarat automatizēt sadarbību un saziņu.
Lai novērtētu šo koordinācijas līmeni, salīdziniet savu CI / CD procesu ar labākajiem biznesa rādītājiem. Tādi uzņēmumi kā Netflix var pabeigt integrāciju, testēšanu un piegādi divu līdz trīs stundu laikā. Viņi izveidoja sistēmu, kas kodu nodod no rokas rokā bez izlēmības un diskusijām. Nē, tas nav simtprocentīgi automatizēts, jo tas nav iespējams ar pašreizējām tehnoloģijām.
CI / CD kļūda # 5: līdzsvarojot nepārtrauktu integrācijas darbu izpildes biežumu un resursu izmantošanu
Ir paredzēts, ka nepārtrauktas integrācijas darbavietas tiek aktivizētas par visām kodā ieviestajām izmaiņām. Veiksmīgi darbi ļauj veikt izmaiņas, savukārt neveiksmes noraida izmaiņas. Tas mudina izstrādātājus pārbaudīt mazākus koda gabalus, izraisot vairāk būvējumu dienā. Tomēr nevajadzīgas nepārtrauktas integrācijas darba vietas patērē resursus, kas lieki tērē laiku un naudu.
Tā kā šis process prasa daudz resursu (CPU, jaudas, laika) izmantošanu, programmatūra būtu jāsadala mazākos komponentos, lai izveidotu ātrāk darbināmus cauruļvadus. Vai arī nepārtrauktās integrācijas darbiem jābūt izveidotiem, lai reģistrētos partijas, kas vispirms tiek pārbaudītas lokāli. Mērķis ir atrast līdzsvaru starp nepārtrauktu integrācijas darbu izpildes biežumu un resursu izmantošanu.
Glabājiet mērķi redzeslokā
Kad mēs iedziļināmies CI / CD slazdos - kopā ar visu tā ezotērisko terminoloģiju - ir viegli aizmirst kāpēc tas ir svarīgi. Galu galā CI / CD ir būtiska, jo tā atbilst biznesa mērķiem.
Tehnoloģiju vadītāji zina, ka nepārtraukta attīstība, ātrie labojumi un kvalitatīvi rezultāti rada un notur klientus. Viņi zina, ka neveiksmīga izlaišana aicina bluķi uz App Store pārskatiem, un augstu atsauksmju atgūšana ir grūtāka nekā to saglabāšana. Devops varētu radīt labāku darba pieredzi jūsu komandai, taču ne tāpēc uzņēmumi ievieš devops.
Vienkārši sakot, CI / CD nepilnības ir vērts pārskatīt, jo uz spēles ir miljardi dolāru. Lai gan es neiesaku jums pievienot krājuma rādītāju vai App Store pārskatu izsekotāju savam CI / CD informācijas panelim, es tomēr aicinu jūs to apzināties. Daudz kas ir atkarīgs no CI / CD sīkumiem.
Zubins Irani ir pilna servisa konsultāciju uzņēmuma cPrime līdzdibinātājs un izpilddirektors, kas īsteno veiklas transformācijas un piegādā veiklus risinājumus vairāk nekā 50 Fortune 100 firmām un daudziem lielākajiem Silīcija ielejas darba devējiem.
Jauno tehnoloģiju forums nodrošina vietu, kur bezprecedenta dziļumā un plašumā izpētīt un pārrunāt topošās uzņēmuma tehnoloģijas. Izvēle ir subjektīva, balstoties uz mūsu izvēlētajām tehnoloģijām, kuras, mūsuprāt, ir svarīgas un interesē lasītājus. nepieņem mārketinga nodrošinājumu publicēšanai un patur tiesības rediģēt visu ieguldīto saturu. Nosūtiet visus jautājumus uz [email protected].
