Razumevanje nenehne integracije in nenehnega uvajanja

Slišali ste CI / CD, vendar niste prepričani, kaj je to?


V idealnem primeru so najeti inženirji programske opreme, da napišejo kodo, ki jo je treba odpreti v proizvodno okolje, da jo lahko podjetja, ki izdelek potrebujejo, uporabijo. Za zadovoljstvo podjetja (ki ga pogosto imenujemo uporabniki / stranke) je nujno, da izdelki niso napak.

Tipičen pristop, ki mu sledijo inženirji programske opreme, je delo v podružnicah in ustvarjanje zahteve po povleku, ki glavno vejo posodobi z novo posodobljeno različico. Prakso pisanja testov smo sprejeli kot sredstvo za zagotovitev, da nove spremembe ne prinašajo napak. Ko razvijalci v večini primerov delajo na funkciji, pogosto ne ustvarijo zahteve po povleku, dokler s svojo funkcijo niso v celoti končani. Ko so pripravljeni, se to zgodi;

  • Veliko časa porabijo za posodobitev svoje zbirke kod s spremembami, ki so se med delovanjem dogajale v proizvodni panogi.
  • Pri tem morajo odpraviti vrsto konfliktov združitve.
  • Obstaja tudi možnost, da prekinejo proizvodno vejo, kar bo vplivalo tudi na tiste, ki potegnejo iz veje, preden se težava vidi in odpravi.

Če ste bili kdaj v tej situaciji, se boste strinjali, da je lahko bolečina – nihče ne želi, da bi svoj delovni dan preživel tako.

Kaj je rešitev?

Nenehna integracija

https://www.youtube.com/watch?v=HnWuIjUw_Q8

Da preprečim zgoraj navedene scenarije; inženirske ekipe lahko sprejmejo tako imenovano prakso stalna integracija – kot že ime pove, vključuje nenehno vključevanje sprememb kode, ki jih razvijalci opravijo v deljeno vejo / skladišče. Koda, ki jo je treba integrirati, mora biti preverjeno preizkušena, da se prepreči, da bi aplikacija zlomila. Integriran je šele, ko test opravi

Da bi to razumeli, si predstavljajmo scenarij iz resničnega življenja, kjer obstaja ekipa 10 razvijalcev. Ti razvijalci lokalno ustvarijo podružnico, v katero napišejo kodo za izvajanje določenih funkcij. Namesto da bi pošiljali zahteve za vleko, ko so v celoti opravljeni s to funkcijo, se odločijo za pošiljanje zahtev za vleko, saj le-te spremenijo malo. Primer takšnih sprememb bo ustvarjanje novega načina, ob predpostavki, da razvijalec deluje na funkciji, ki uporabnikom omogoča upravljanje posameznih nalog v aplikaciji. Namesto da bi čakali, da se funkcija opravila zaključi, da se drži neprekinjenega vzorca integracije, razvijalca pritisne na to majhno spremembo (v primerjavi s tistim, za katero dela) in ustvari povlečno zahtevo za združitev s kodo.

Preden se ta nova sprememba vključi, je treba opraviti vrsto preskusov.

Ekipe programskega inženiringa uporabljajo orodja, kot so Travis CI za ustvarjanje teh integracijskih procesov in testov. Z orodji, kot je ta, so testi samodejni, tako da se začnejo takoj, ko se v ciljno vejo, izbrano med namestitvijo, vloži zahtevek za vleko..

Rezultati testov so ustvarjeni, razvijalci, ki so ustvarili zahteve za povleko, pa si lahko ogledajo rezultate in izvedejo potrebne spremembe. Prednosti, da se držimo tega vzorca čim manjšega vključevanja kode in preverjenega preizkusa, so;

  • Vpletena skupina lahko ve, kaj je povzročilo postopek gradnje ali preizkusa. To zmanjšuje možnost pošiljanja hrošča v proizvodnjo.
  • Če ekipa avtomatizira postopek, jim bo na voljo čas, da se osredotočijo na produktivnost.

Pomembno pri tej praksi je, da spodbuja ekipo, da pogosto pošilja kodo v glavno vejo. To bo neučinkovito, če se drugi člani ekipe ne bodo potegnili iz glavne veje, da bi posodobili svoje lokalno skladišče.

Vrste preskusov

Pri pisanju testov, ki bodo del procesa integracije, je nekaj, ki jih je mogoče izvajati v postopku:

  • Integracija – združuje posamezne enote programske opreme in jih preizkuša kot skupino.
  • Enota – preizkuša posamezne enote ali komponente programske opreme, kot so metode ali funkcije.
  • Uporabniški vmesnik – trdi, da programska oprema deluje dobro z vidika uporabnika.
  • Sprejemljivost – testi, ki jih programska oprema ustreza poslovnim zahtevam.

Pomembno je upoštevati, da vam vsega tega ni treba preizkušati, saj jih je peščica morda že zajeta v kodi, ki jo je napisal razvijalec.

Orodja za nenehno vključevanje

Ne da bi se spuščali v globino, tukaj so orodja, ki jih lahko začnete uporabljati v svojih trenutnih ali novih projektih;

  • Travis CI – znana v svetu odprte kode in obljublja, da boste kodo brezhibno preizkusili v nekaj minutah.
  • Krog CI – zagotavlja vam moč, prilagodljivost in nadzor za avtomatizacijo cevovoda od nadzora do uvajanja.
  • Jenkins – ponuja na stotine vtičnikov za podporo pri gradnji, uvajanju in avtomatizaciji katerega koli projekta.

Če ste novi Jenkins, bi predlagal, da to vzamete Seveda Udemy spoznati CI z Javo in .NET.

Nenehno uvajanje

Kakšne koristi bo, če funkcija, ki jo izdelate, ostane v skladišču tedne ali mesece, preden bo nameščena v proizvodno okolje. Kolikor se inženirske ekipe lahko potrudijo k vključevanju majhnih sprememb v glavno vejo, lahko te spremembe čim prej potisnejo v proizvodno okolje..

Cilj neprekinjene uvajanja je doseči spremembe uporabnikov takoj, ko razvijalci te spremembe vključijo v glavno vejo.

Tako kot v primeru neprekinjene integracije se tudi pri uporabi neprekinjene uvajanja samodejno testirajo in preverjajo, da se preverijo novo integrirane spremembe. Uvajanje se zgodi šele, ko se ti preskusi opravijo.

Da bi imela skupina koristi od prakse neprekinjenega uvajanja, morajo imeti naslednje;

  • Samodejno testiranje je bistvena osnova vseh neprekinjenih inženirskih praks. V primeru nenehnega uvajanja mora biti koda, ki jo je treba uporabiti, v skladu s standardom, ki ga je ekipa postavila, za kar nameravajo izstaviti končne uporabnike. V idealnem primeru je, če je nova sprememba pod pragom, test ne bo uspel in se ne vključuje. Drugače, postane integriran.
  • Kljub temu, da imamo avtomatizirane teste od zadaj, je možno, da bodo nekatere napake zdrsnile v proizvodno okolje. Za to je nujno, da lahko ekipa razveljavi opravljeno spremembo – razveljavi napotitev. To bi moralo spremeniti proizvodno kodo na tisto, kar je bilo pred novo spremembo.
  • Sistemi za spremljanje so potrebni za spremljanje sprememb, ki so bile potisnjene v proizvodno okolje. Tako lahko ekipa spremlja sledenje hroščev, s katerimi se uporabniki srečujejo, ko uporabljajo uvedene spremembe.

Orodja, omenjena za neprekinjeno integracijo, vam nudijo tudi funkcijo za nastavitev sistema neprekinjenega uvajanja. Veliko jih je, o katerih si lahko tudi preberete.

Zaključek

Produktivnost razvojne ekipe je ključnega pomena za uspeh podjetja. Za zagotovitev njihove produktivnosti je treba sprejeti prakse, ki to spodbujajo. Nenehno povezovanje in uvajanje sta primera takšnih praks.

S stalnim povezovanjem lahko ekipe dnevno potisnejo čim več kode. S tem dosežemo, da uporabnika na novo dodate nove spremembe čim prej. Z uvedbo teh sprememb lahko uporabniki dobijo povratne informacije. Na koncu bo podjetje lahko inovativno temeljilo na prejetih povratnih informacijah, kar je za vse dobro.

Če ste razvijalec in se želite učiti CI / CD, to preverite sijajen tečaj.

Jeffrey Wilson Administrator
Sorry! The Author has not filled his profile.
follow me
    Like this post? Please share to your friends:
    Adblock
    detector
    map