Patiesā atšķirība starp nepārtrauktu integrāciju un nepārtrauktu ieviešanu

Tur ir daudz satura, kas raksturo nepārtrauktu integrāciju, nepārtrauktu piegādi un nepārtrauktu ieviešanu. Bet kādiem mērķiem šie procesi vispirms kalpo?

Lai pareizi izmantotu CI un CD, ir ļoti svarīgi izprast problēmas. Tas ļaus jūsu komandai uzlabot jūsu procesu un izvairīties no piepūles, lai dzītu iedomātā metriku, kas jūsu procesam nerada nekādu vērtību.

Nepārtraukta integrācija ir komandas problēma

Ja strādājat komandā, iespējams, ka vienā repozitorijā strādā vairāki izstrādātāji. Repozitorijā ir galvenā filiāle, kurā atrodas koda jaunākā versija. Izstrādātāji strādā pie dažādām lietām dažādās nozarēs. Kad kāds ir izdarījis izmaiņas, viņš to nospiež vai apvieno galvenajā filiālē. Galu galā visa komanda pievērsīs šīs izmaiņas.

Scenārijs, no kura mēs vēlamies izvairīties, ir tāds, ka kļūdaina apņemšanās nonāk galvenajā nozarē. Bojāts nozīmē, ka kods netiek apkopots vai lietotne netiks startēta vai ir nelietojama. Kāpēc? Ne tāpēc, ka lietotne ir bojāta, vai tāpēc, ka visiem testiem vienmēr jābūt zaļiem. Tā nav problēma - jūs varat izlemt šo versiju neizvietot un gaidīt labojumu.

Problēma ir tā, ka visa jūsu komanda ir iestrēdzis. Visi izstrādātāji, kuri izvilka kļūdaino apņemšanos, 5 minūtes pavadīs, domājot, kāpēc tas nedarbojas. Vairāki, iespējams, mēģinās atrast kļūdaino apņemšanos. Daži mēģinās paši novērst problēmu paralēli kļūdainā koda autoram.

Tas ir laika izšķiešana jūsu komandai. Sliktākais ir tas, ka atkārtoti incidenti veicina neuzticēšanos galvenajai nozarei un mudina izstrādātājus strādāt atsevišķi.

Nepārtrauktas integrācijas mērķis ir novērst galveno filiāles pārrāvumu, lai jūsu komanda nebūtu iestrēdzis. Tieši tā. Tas nenozīmē, ka visi testi vienmēr ir zaļi un galvenā nozare ir izvietojama ražošanā katrā apņemšanās reizē.

Nepārtrauktas integrācijas process ir neatkarīgs no jebkura rīka. Jūs varētu manuāli pārbaudīt, vai jūsu filiāles un galvenā filiāles apvienošana darbojas lokāli, un tad apvienošanu faktiski var virzīt tikai uz krātuvi. Bet tas būtu ļoti neefektīvi. Tāpēc nepārtraukta integrācija tiek ieviesta, izmantojot automatizētas pārbaudes.

Pārbaudes nodrošina, ka vismaz:

  • Lietotnei vajadzētu izveidot un sākt
  • Vissvarīgākajām funkcijām vienmēr jābūt funkcionālām (lietotāja reģistrēšanās / pieteikšanās ceļš un galvenās biznesa funkcijas)
  • Lietotnes kopējiem slāņiem, uz kuriem paļaujas visi izstrādātāji, jābūt stabiliem. Tas nozīmē vienību testus šīm daļām.

Praksē tas nozīmē, ka jums jāvelk jebkura vienības testa sistēma, kas jums darbojas, un jānodrošina kopējie lietojumprogrammas slāņi. Dažreiz tas nav tik daudz koda, un to var izdarīt diezgan ātri. Jums arī jāpievieno "dūmu tests", pārbaudot, vai kods tiek apkopots un vai programma tiek palaista. Tas ir īpaši svarīgi tehnoloģijās ar traks atkarības injekcijām, piemēram, Java Spring vai .NET core. Lielos projektos ir tik viegli savaldīt atkarības, ka ir jāpārbauda, ​​vai lietotne vienmēr tiek palaista.

Ja jums ir simtiem vai tūkstošiem testu, tie nav jāveic katrā apvienošanā. Tas prasīs daudz laika, un lielākā daļa testu, iespējams, pārbauda “bez komandas bloķētāja” funkcijas.

Mēs redzēsim nākamajās sadaļās, kā nepārtrauktas piegādes process labi izmantos šos daudzos testus.

Tas nav par rīkiem

Rīki un automātiskās pārbaudes ir labi. Bet, ja jūsu izstrādātāji apvieno tikai milzu filiāles, pie kurām strādā nedēļas, viņi jums nepalīdzēs. Komanda pavadīs labu laiku, apvienojot filiāles un novēršot koda neatbilstības, kas galu galā radīsies. Tā ir tikpat daudz laika izšķiešana kā bloķēšana ar kļūdainu apņemšanos.

Nepārtraukta integrācija nav saistīta ar rīkiem. Tas ir par darbu mazos gabalos un jaunā koda integrēšanu galvenajā filiālē un biežu vilkšanu.

Bieži nozīmē vismaz katru dienu. Sadaliet uzdevumu, pie kura strādājat, mazākos uzdevumos. Ļoti bieži sapludiniet savu kodu un ļoti bieži velciet to. Tādā veidā neviens nestrādā ilgāk par dienu vai divām, un problēmām nav laika kļūt par sniega bumbiņām.

Lielam uzdevumam nav jābūt visu vienā filiālē. Tā nekad nevajadzētu būt. Paņēmienus, lai nepabeigtos darbus apvienotu ar galveno atzaru, sauc par "atzarošanu pēc abstrakcijas" un "funkciju pārslēgšanu". Plašāku informāciju skatiet emuāra ziņā Kā sākt darbu ar nepārtrauktu integrāciju.

Galvenie punkti labai KI veidošanai

Tas ir ļoti vienkārši. Īsi sakiet. 3-7 minūtēm jābūt maks. Tas nav par CPU un resursiem. Tas ir par izstrādātāju produktivitāti. Pirmais produktivitātes noteikums ir fokuss. Dariet vienu lietu, pabeidziet to, pēc tam pārejiet pie nākamās.

Konteksta maiņa ir dārga. Pētījumi rāda, ka dziļi pārorientējoties uz kaut ko, kad traucē, paiet ~ 23 minūtes.

Iedomājieties, ka jūs virzāt savu filiāli, lai to apvienotu. Jūs sākat citu uzdevumu. Jūs pavadāt 15-20 minūtes, iekļūstot tajā. Minūti pēc tam, kad atrodaties zonā, saņemat paziņojumu "būvēšana neizdevās" no 20 minūšu ilgā KI būves par iepriekšējo uzdevumu. Jūs atgriežaties, lai to labotu. Jūs to atkal nospiežat. Jūs viegli zaudējāt vairāk nekā 20 minūtes, pārvietojoties turp un atpakaļ.

Reiziniet 20 minūtes vienu vai divas reizes dienā ar izstrādātāju skaitu savā komandā ... Tas ir daudz izniekots dārgais laiks.

Tagad iedomājieties, vai atsauksmes atgriezās 3 minūšu laikā. Jūs, iespējams, nemaz nebūtu sākuši jauno uzdevumu. Jums būtu pierādījums, ka jūs vēl vienu reizi izlasīsit savu kodu, vai gaidīšanas laikā pārskatīsit PR. Neizdevās paziņojums, un jūs to labosiet. Tad jūs varētu pāriet uz nākamo uzdevumu. Tas ir sava veida fokuss, kas jāaktivizē jūsu procesam.

Īsa CI uzbūve padara to par kompromisu. Testi, kas darbojas ilgāk vai nodrošina nelielu vērtību KI kontekstā, jāpārvieto uz CD soli. Un jā, arī tur ir jānovērš neveiksmes. Bet, tā kā tie neliedz nevienam darīt savu lietu, jūs varat uztvert labojumus kā "nākamo uzdevumu", kad esat pabeidzis savu darbību. Strādājot, vienkārši izslēdziet paziņojumus un ik pa brīdim pārbaudiet. Saglabājiet minimālu konteksta pārslēgšanos.

Nepārtraukta piegāde un ieviešana ir inženiertehniskas problēmas

Apmetīsimies definīcijās, lai to novērstu.

Nepārtrauktas piegādes mērķis ir visu laiku izvietot jebkuru sava koda versiju. Praksē tas nozīmē jūsu koda pēdējo vai iepriekšējo versiju. Jūs neizvietojat automātiski, parasti tāpēc, ka jums nav vai ir ierobežots jūsu projekta dzīves cikls. Bet tiklīdz kāds to vēlas, izvietošanu var veikt minimālā laikā. Ka kāds var būt testa / kvalitātes nodrošināšanas komanda, kas vēlas izmēģināt lietas iestudējuma vai pirmsražošanas vidē. Vai arī faktiski var būt laiks izlaist kodu ražošanai.

Nepārtrauktas piegādes ideja ir sagatavot artefaktus pēc iespējas tuvāk tam, ko vēlaties palaist savā vidē. Tie var būt .jar vai .war faili, ja strādājat ar Java, vai izpildāmie faili, ja strādājat ar .NET. Tās var būt arī pārsūtīta JS koda mapes vai pat Docker konteineri, neatkarīgi no tā, kas padara izvietošanu īsāku (ti, jūs jau iepriekš esat izveidojis tik daudz, cik vien iespējams).

Ar artefaktu sagatavošanu es nedomāju koda pārvēršanu artefaktos. Parasti tie ir daži skripti un izpildes minūtes. Sagatavošana nozīmē:

Veiciet visus iespējamos testus, lai pārliecinātos, ka pēc izvietošanas kods patiešām darbosies. Veiciet vienības testus, integrācijas testus, gala testus un pat veiktspējas testus, ja to varat automatizēt.

Tādā veidā jūs varat filtrēt, kuras galvenās filiāles versijas faktiski ir gatavas ražošanai un kuras vēl nav. Ideāls testa komplekts:

  • Nodrošina lietojumprogrammas galveno funkciju darbību. Ideālā gadījumā visas funkcijas
  • Nodrošina, ka nav ieviests neviena veiktspējas darījumu pārtraucēja, tāpēc, kad jūsu jaunā versija nonāk jūsu daudzos lietotājiem, tai ir iespēja pastāvēt
  • Jebkurš datu bāzes atjauninājums, kas nepieciešams jūsu kodam, lai izvairītos no pārsteigumiem

Tam nav jābūt ļoti ātram. 30 minūtes vai 1 stunda ir pieņemama.

Nepārtraukta izvietošana ir nākamais solis. Kādā vidē jūs izvietojat vismodernāko un gatavāko koda versiju. Ideālā gadījumā, ja pietiekami uzticaties savam kompaktdisku testu komplektam.

Ņemiet vērā, ka atkarībā no konteksta tas ne vienmēr ir iespējams vai ir vērts pūles. Nepārtraukta piegāde bieži ir pietiekama, lai tā būtu produktīva, it īpaši, ja strādājat ciešā tīklā un jums ir ierobežota vide, kurā varat izvietot. Var būt arī tas, ka programmatūras izlaišanas cikls novērš neplānotu izvietošanu.

Nepārtraukta piegāde un nepārtraukta ieviešana (turpmāk sauksim tos par CD) nav komandas problēmas. Tie ir par pareizā līdzsvara atrašanu starp izpildes laiku, apkopes darbiem un testu komplekta atbilstību, lai varētu pateikt "Šī versija darbojas kā nākas".

Un tas ir līdzsvars. Ja jūsu testi ilgst 30 stundas, tā ir problēma. Skatiet šo episko ierakstu par to, kā izskatās Oracle datu bāzes testa komplekts. Bet, ja jūs pavadāt tik daudz laika, lai testus atjauninātu ar jaunāko kodu, ka tas kavē komandas progresu, arī tas nav labi. Arī tad, ja jūsu testa komplekts gandrīz neko nenodrošina ... būtībā tas ir bezjēdzīgi.

Ideālā pasaulē mēs vēlamies vienu izvietojamu artefaktu komplektu uz katru galveno nozari. Var redzēt, ka mums ir vertikālas mērogojamības problēma: jo ātrāk mēs pārietam no koda uz artefaktiem, jo ​​gatavāki esam izvietot jaunāko koda versiju.

Kāda ir liela atšķirība?

Nepārtraukta integrācija ir horizontāla mērogojamības problēma. Jūs vēlaties, lai izstrādātāji bieži apvieno savu kodu, tāpēc pārbaudēm jābūt ātrām. Ideāli dažu minūšu laikā, lai izvairītos no tā, ka izstrādātāji visu laiku maina kontekstu, izmantojot ļoti asinhronas atsauksmes no KI būvēm.

Jo vairāk izstrādātāju jums ir, jo lielāka skaitļošanas jauda nepieciešama visu aktīvo atzaru vienkāršai pārbaudei (būvēšanai un testēšanai).

Laba CI uzbūve: Nodrošina, ka galvenajā filiālē netiek ieviests kods, kas pārtrauc pamata lietas un neļauj citiem komandas locekļiem strādāt, un tas ir pietiekami ātrs, lai dažu minūšu laikā sniegtu atgriezenisko saiti izstrādātājiem, lai novērstu konteksta pārslēgšanos starp uzdevumiem.

Nepārtraukta piegāde un izvietošana ir vertikālas mērogojamības problēmas. Jums jāveic viena diezgan sarežģīta darbība.

Laba kompaktdiska versija: nodrošina, ka pēc iespējas vairāk funkciju darbojas pareizi. Jo ātrāk, jo labāk, bet tas nav ātruma jautājums. 30–60 minūšu būvējums ir kārtībā.

Bieži sastopams nepareizs uzskats ir uzskatīt kompaktdisku par horizontālu mērogojamības problēmu, piemēram, CI: jo ātrāk jūs varat pāriet no koda uz artefaktiem, jo ​​vairāk apņemšanās jūs faktiski varat apstrādāt, un jo tuvāk varat atrast ideālo scenāriju.

Bet mums tas nav vajadzīgs. Artefaktu izgatavošana katrai izdarīšanai un pēc iespējas ātrāk parasti ir pārmērīga. Jūs varat ļoti labi piekļūt kompaktdiskam pēc vislabākajiem centieniem: izveidojiet vienu kompaktdisku, kas tikai izvēlēsies jaunāko apņemšanos pārbaudīt, kad konkrētā būve būs pabeigta.

Nekļūdieties ar CD. Tas ir patiešām grūti. Lai sasniegtu pietiekamu testa uzticamību, lai teiktu, ka programmatūra ir gatava izvietošanai automātiski, parasti tā darbojas zemas virsmas lietojumprogrammās, piemēram, API vai vienkāršās lietotāja saskarnēs. Sarežģītā lietotāja saskarnē vai lielā monolītā sistēmā to ir ļoti grūti panākt.

Secinājums

CI un CD izpildei izmantotie rīki un principi bieži ir ļoti līdzīgi. Mērķi tomēr ir ļoti atšķirīgi.

Nepārtraukta integrācija ir kompromiss starp atgriezeniskās saites ātrumu izstrādātājiem un jūsu veikto pārbaužu (veidošanas un testēšanas) atbilstību. Nevienam kodam, kas kavētu komandas progresu, nevajadzētu nokļūt galvenajā filiālē.

Nepārtraukta izvietošanas piegāde ir pēc iespējas rūpīgāka pārbaude, lai novērstu koda problēmas. Pārbaužu pilnīgums ir vissvarīgākais faktors. To parasti mēra pēc testa pārklājuma vai funkcionālā pārklājuma. Kļūdu savlaicīga notveršana novērš bojāta koda izvietošanu jebkurā vidē un ietaupa dārgo testa komandas laiku.

Izstrādājiet savu CI un CD veidojumus, lai sasniegtu šos mērķus un saglabātu komandas produktivitāti. Neviena darbplūsma nav ideāla. Šad un tad radīsies problēmas. Izmantojiet tos kā gūtās mācības, lai katru reizi to stiprinātu.

Publicēts 2019. gada 27. novembrī emuārā Fire CI.