Nuolatinės integracijos ir nuolatinio diegimo supratimas

Girdėjote CI / CD, bet nežinote, kas tai yra?


Geriausia, jei programinės įrangos inžinieriai yra samdomi rašyti kodą, kurį reikia išsiųsti į gamybos aplinką, kad verslas, kuriam reikalingas produktas, galėtų juo naudotis. Norint patenkinti verslą (dažnai vadinamą vartotojais / klientais), labai svarbu, kad produktai būtų be klaidų.

Įprastas požiūris, kurio laikosi programinės įrangos inžinieriai, yra darbas šakose ir sukuriant užklausos užklausą, kuri atnaujina pagrindinę šaką atliktu nauju atnaujinimu. Mes pasirinkome testų rašymo praktiką kaip priemonę, užtikrinančią, kad nauji pakeitimai nepateiktų klaidų. Kai kūrėjai daugeliu atvejų dirba su funkcija, jie dažnai nesukuria įtraukimo užklausos, kol visiškai nepadarė šios funkcijos. Kas nutinka, kai jie yra pasirengę, tai yra;

  • Jie praleidžia daug laiko bandydami atnaujinti savo bazinę bazę su pakeitimais, kurie įvyko gamybos padalinyje jiems dirbant..
  • Tai darydami, jie turi išspręsti susijungimo konfliktus.
  • Taip pat yra galimybė, kad jie sulaužys gamybos šaką, o tai turės įtakos tiems, kurie traukiasi iš šakos, kol problema nėra pastebima ir neišsprendžiama..

Jei kada nors esate buvę tokioje situacijoje, sutiksite, kad tai gali būti skausmas – niekas nenoriai mėgsta praleisti tokią savo darbo dieną kaip ši.

Koks sprendimas?

Nuolatinė integracija

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

Norėdami užkirsti kelią minėtiems scenarijams; inžinerijos komandos gali priimti vadinamąją praktiką nuolatinė integracija – kaip rodo pavadinimas, tai apima nuolatinį kūrėjų atliktų kodų pakeitimų integravimą į bendrą filialą / saugyklą. Integruotinas kodas turi būti patikrintas ir patikrintas, ar jis nepažeidžia programos. Jis integruotas tik tada, kai testas praeina

Norėdami tai suprasti, įsivaizduokime realaus gyvenimo scenarijų, kuriame yra 10 kūrėjų komanda. Šie kūrėjai sukuria filialą vietoje, kuriame užrašo kodą tam tikroms funkcijoms įgyvendinti. Užuot siuntę užklausas, kai jie visiškai atlikti su šia funkcija, jie pasirenka siųsti užklausas, nes jie nedaug keičiasi. Tokio pakeitimo pavyzdys bus naujo modulio sukūrimas, jei kūrėjas dirba su funkcija, leidžiančia vartotojams valdyti atskiras programos užduotis. Vietoj to, kad lauktų, kol užduoties funkcija bus atlikta, kad būtų laikomasi nenutrūkstamo integravimo modelio, kūrėjas stumia šį nedidelį pakeitimą (palyginti su tuo, ką ji dirba) ir sukuria traukimo prašymą sujungti su kodu.

Prieš integruojant šį naują pakeitimą, reikia atlikti daugybę bandymų.

Programinės įrangos inžinerijos komandos naudoja tokias priemones kaip „Travis CI“ sukurti šiuos integracijos procesus ir testus. Naudojant tokius įrankius, bandymai yra automatizuoti, kad jie būtų vykdomi iškart, kai tik pateikimo užklausa bus pateikta į tikslinę šaką, pasirinktą sąrankos metu..

Sugeneruojami bandymų rezultatai, o kūrėjas, sukūręs užklausų perkėlimą, gali pamatyti rezultatus ir atlikti reikiamus pakeitimus. Privalumai, kuriuos galima laikytis norint kuo mažiau integruoti kodą ir turėti patikrintą testą;

  • Dalyvaujančiai komandai tampa įmanoma žinoti, kas sukėlė kūrimo procesą ar testą. Tai sumažina klaidos gabenimo į gamybą galimybę.
  • Jei komanda automatizuoja procesą, jie turės laiko prabangiai skirti dėmesį produktyvumui.

Svarbu atkreipti dėmesį į šią praktiką, kad ji skatina komandą dažnai stumti kodą į pagrindinę šaką. Tai padaryti neveiks, jei kiti komandos nariai nesitraukia iš pagrindinės filialo atnaujinti savo vietinės saugyklos.

Testų rūšys

Rašydami testus, kurie bus integracijos proceso dalis, čia pateikiame kelis šiuos procesus:

  • Integracija – ji sujungia atskirus programinės įrangos vienetus ir išbando juos kaip grupę.
  • Vienetas – tai atskirų programinės įrangos vienetų ar komponentų, tokių kaip metodai ar funkcijos, bandymai.
  • UI – patvirtina, kad programinė įranga veikia gerai iš vartotojo perspektyvos.
  • Priėmimas – testai, ar programinė įranga atitinka verslo reikalavimus.

Svarbu atminti, kad jums nereikia išbandyti visų šių dalykų, nes keletas jų jau gali būti įtraukti į kūrėjo parašytą kodą.

Nuolatinės integracijos įrankiai

Nesigilinant į tai, čia yra priemonės, kuriomis galite pradėti naudotis įgyvendindami dabartinius ar naujus projektus;

  • „Travis CI“ – žinomas atvirojo kodo pasaulyje ir žada, kad jūsų kodas bus lengvai patikrintas per kelias minutes.
  • CI apskritimas – suteikia galią, lankstumą ir valdymą automatizuojant dujotiekį nuo valdymo iki diegimo.
  • Jenkinsas – teikia šimtus papildinių, padedančių kurti, diegti ir automatizuoti bet kurį projektą.

Jei esate naujokas Jenkinsas, tada siūlyčiau tai padaryti Udemy kursas išmokti CI naudojant Java ir .NET.

Nuolatinis dislokavimas

Kas bus gerai, jei jūsų sukurta funkcija saugykloje bus saugoma keletą savaičių ar mėnesių, kol ji nebus įdiegta į gamybos aplinką. Inžinerijos komandos gali stengtis integruoti nedidelius pakeitimus į pagrindinę filialą, kaip įmanoma, jie taip pat gali šiuos pokyčius kuo greičiau perkelti į gamybos aplinką..

Nepertraukiamo diegimo tikslas yra priversti vartotojus atlikti pakeitimus, kai tik kūrėjai integruoja šiuos pakeitimus į pagrindinę šaką..

Kaip ir nuolatinės integracijos atveju, naudojant nepertraukiamą diegimą, siekiant užtikrinti, kad naujai integruoti pakeitimai būtų patikrinti, nustatomi automatiniai bandymai ir tikrinimai. Diegimas įvyksta tik tada, kai šie testai praeina.

Kad komanda gautų naudos iš nuolatinio dislokavimo praktikos, jie turi turėti šiuos dalykus:

  • Automatizuotas testavimas yra pagrindinis nuolatinės inžinerijos praktikos pagrindas. Nuolatinio diegimo atveju dislokuotinas kodas turi atitikti standartą, kurį komanda nustatė tam, ką jie ketina išstumti galutiniams vartotojams. Geriausia, jei naujas pakeitimas nesiekia slenksčio, testas turėtų būti nesėkmingas ir jo nereikėtų integruoti. Kitaip ji tampa integruota.
  • Nepaisant automatinių bandymų, gali būti, kad kai kurios klaidos pateks į gamybos aplinką. Tam reikia, kad komanda sugebėtų anuliuoti padarytą pakeitimą – atšaukti dislokavimą. Tai turėtų grąžinti gamybos kodą į tokį, koks jis buvo prieš atliekant naują pakeitimą.
  • Stebėjimo sistemos yra reikalingos, kad būtų galima sekti pokyčius, kurie buvo perkelti į gamybos aplinką. Taip komanda gali atsekti klaidas, su kuriomis vartotojai susiduria naudodamiesi įdiegtais pakeitimais.

Nepertraukiamai integracijai paminėti įrankiai taip pat suteikia jums galimybę nustatyti nenutrūkstamo diegimo sistemą. Jų yra daugybė, apie kuriuos taip pat galite perskaityti.

Išvada

Plėtros komandos produktyvumas yra gyvybiškai svarbus sėkmingam verslui. Norint užtikrinti jų produktyvumą, reikia imtis praktikų, kurios tai skatina. Tokios praktikos pavyzdžiai yra nuolatinė integracija ir diegimas.

Nuolat integruodamiesi, komandos gali kiekvieną dieną stumti kuo daugiau kodų. Tai pasiekus, tampa lengva kuo greičiau įdiegti naujai pridėtus pakeitimus vartotojui. Įdiegus šiuos pakeitimus, galima gauti grįžtamąjį ryšį iš vartotojų. Galų gale verslas galės diegti naujoves remdamasis gautais atsiliepimais, kurie yra naudingi visiems.

Jei esate kūrėjas ir norite išmokti CI / CD, tada patikrinkite tai puikus kursas.

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