Kuidas saada pidevat integratsiooni õigesti

Saladus, mida täiskäigul pakkuda on, ei puuduta teie tööriistu

Autor Nathaniel Tetteh saidil Unsplash. Nii saavutate pideva integratsiooni.

Olen tegelenud tarkvaraarendusega juba aastaid. Berliinis elamine aitab mul ka suhelda tohutu alustava kogukonnaga.

Mulle meeldib rääkida erinevate ettevõtete inimestega, et näha, kuidas nende protsessid välja näevad ja milline on nende kultuur meeskondade, kodeerimise tavade ja kvaliteedistandardite osas.

Pideva integratsiooni teemal arutades on muster, mida ma sagedamini märkan. Pole harvad juhud, kui arendajad räägivad sellest justkui ainult Jenkinsist või Travisest või nende kasutatavast tööriistast.

Ilmselt tähendab pidev integreerimine paljudes keskkondades lihtsalt tööriista olemasolu, mis kontrollib teie viimast pühendumist ja muutub vastavalt tulemusele punaseks või roheliseks nagu Xmas tree.

Ma pole nõus.

On olemas põhimõttelised tavad ja protsessid, mis on enne iga tööriista kasutamist, mida saaksite kasutada ja mis on pideva integratsiooni aluseks.

Ilma nendeta pole CI lihtsalt võimalik.

Selles postituses loetlen mõned neist. Ma arvan, et need on heaks lähtepunktiks tõelise pideva integratsiooni saavutamiseks.

Kui kuulute meeskonda, kes pingutab toimetuleku nimel või kui te ei suuda oma kodeerimisega seotud pingutusi oma meeskonna eakaaslastega kooskõlastada, siis on see postitus teie jaoks.

Funktsioonide harud puuduvad

Kui meeskonnad seisavad silmitsi ülesandega töötada välja uus funktsioon, on nende tehtud tavaline viga avada hoidlas funktsiooniharu ja asuda sellesse paljusid ülesandeid viskama.

Idee on isoleerida end kogu projekti hõlmavatest arendusprotsesside piirangutest, kuni funktsioon on lõpule viidud ja selle saab uuesti peamiseks ühendada.

Funktsiooniharu git töövoo esindamine

Selle praktika mõte on enam-vähem „kui me töötame otseselt meistri kallal ja kapten on ühendatud väljalasketsükliga, siis vabastame poole toetatud funktsiooni või midagi, mis veel ei tööta. Veelgi hullem, me võime midagi rikkuda, kuna me pole oma koodi täielikult testinud ”.

Ehkki see tava võib tunduda konservatiivne ja ohutusele orienteeritud, on see täiesti vastupidine.

Enamasti jõuab teil katkine väljalase kohe pärast funktsiooni haru tagasi ühendamist. Teie ainsateks võimalusteks on: a) tühistada kohustus või b) vabastada versioon kuumalt.

Kui teil pole õnne, võivad mõlemad olla kallid ja veaohtlikud.

Kui teie vabastamisprotsess pole piisavalt automatiseeritud, võib sellise suure kohustuse tagasipöördumine maksta teile näiteks andmebaasi struktuuri käsitsi tagasipööramise. Ja mida te teete, kui muudate oma andmeid hävitavalt?

Kuumkinnitamine pole samuti vähem riskantne. Kasutajakogemuse häirimise minimeerimiseks peate plaastri vabastama nii kiiresti kui võimalik. Ja me kõik teame, et ajaline surve ei tule läbimõeldud arenguga üldse toime. Risk on lisada vigu lisaks vigadele ja halvendada olukorda üle vastuvõetava piiri.

Miks funktsiooniharud ei tööta?

Põhjus, miks funktsioonide harud ei tööta, on lihtne: arendamise ajal ei saa te pidevat tagasisidet.

Kui teie ja teie meeskond ei anna sidusrühmale võimalust oma pooleliolevat tööd pidevalt kinnitada, kaotate kontakti reaalsusega.

Teil pole oma arenemisprotsessi valideerimiseks muud võimalust, kui lubada oma kasutajal pidevalt sisse logida.

Sellisel juhul on paljude arendajate jaoks tegemist eksimisega. See on veendumus, et kui nad testivad oma koodi piisavalt, kirjutades testid või käsitsi klõpsates, võivad nad olla kindlad, et äsja välja töötatud toimib lihtsalt ™.

See on viga ja seda tuleb iga hinna eest vältida.

Nii palju kui te arendajana võite proovida mõelda nagu teie kasutaja (d), siis te lihtsalt pole. Kasutusharjumusi eiratakse ja neid ei rakendata. Käitumist ei nähta ette, see avab ukse alatudele vigadele. Ärijuhtumeid või sügavaid protsesse ei leita.

Teisisõnu, teie tarkvara ei rakenda parimal juhul seda, mis tegelikult on. Või läheb see lihtsalt katki ja halvimal juhul ei tööta lihtsalt. Mõlemal juhul näib see kasutaja silmis vale.

Ehkki Feature Branch mudel võib tunduda konservatiivne ja ohutusele orienteeritud, on see täiesti vastupidine.

Kasutage funktsiooni lülitusi

Esimene, lihtne samm CI hea taseme saavutamiseks on funktsiooni lülitite kasutamine.

Funktsiooni ümberlülitamine on teie rakenduse konfiguratsioonilipp, mis võib konkreetse funktsiooni sisse ja välja lülitada.

Seda tehnikat on tohutult lihtne rakendada. Teie koodibaasis näeb see välja enam-vähem selline.

Funktsioonilülituse kasutamise eelised on järgmised:

  • saate funktsiooni tootmises välja lülitada, ilma et peaksite seda uuesti vabastama. See on kasulik, kui teatatakse kriitilisest veast ja soovite takistada kasutajatel juurdepääsu katkisele funktsioonile;
  • saate selle funktsiooni kanaari keskkonnas lubada ja selle tootmisesse jätta. See võimaldab varajases staadiumis kasutajatel funktsiooni testida ja arendusmeeskond kogub kasulikku tagasisidet enne ametlikku väljaandmist;
  • saate funktsiooni suletud keskkonnas lubada ja näiteks tootehalduril lubada tehnika taset kontrollida ka siis, kui funktsioon pole veel valmis.

Funktsioonide ümberlülitamiste kasutamisel saab lahti veel ühe eelise.

Kuna teie funktsiooni saab tootmise ajal välja lülitada, kuni see on lõpule jõudnud ja stabiilne, saate nüüd alustada kohustuste liitmist otse oma peaharusse.

Väike kohustub otse kaptenile

Selle mudeli järgimisel oma kohustuste otse meistriks liitmiseks on paar mõjuvat põhjust.

Ühinev mudel „Hüppavad kalad“.

Kes seda tegi?

Esimene põhjus on see, et saate oma koodist puhtama ajaloo. Sa tead täpselt, kes mida tegi. See aitab palju, kui teised arendajad vajavad koodi konkreetse osa kohta selgitusi.

Funktsioonharude abil jagatakse kõik ülesanded enne ühendamist ühte, nii et teave kaob ja ainult üks arendaja võtab kõik süüdi.

Lihtne ühendamine, vähem konflikte, turvalisem tagasipöördumine

Mida suurem on funktsiooniharu, seda suurem on tõenäosus, et teil tekivad liitmiskonfliktid.

Ühendamiskonfliktid võivad olla väga valusad, kuna nende lahendamine on puhtalt käsitsi teostatav ja äärmiselt veaohtlik protsess.

Lisaks peate liitumiskonflikti ees tõenäoliselt oma rakenduse loogikat natuke ümber töötama. Tavaliselt tehakse seda rebenemise ajal lennult. Lasin teil ette kujutada, milline võib olla kodeerimise kvalitatiivne tulemus, kui teie aju on keset muud ülesannet.

Nägin mitu korda arendajaid öelmas: „Ei tea, mis juhtus. Lahendasin mõned konfliktid ja segasin rebase ajal midagi. ” Võib-olla on gitil vigu, kuid ma väga kahtlen, kas see võib segamini ajada.

Väiksemad kohustused võimaldavad teil olla turvalisel poolel ja vältida keerulisi taasesinemisi. Konfliktid on minimaalsed ja triviaalsed, sest ka muutuste pinnalaiendus on liiga suur.

Väiksemaid kohustusi on ka psühholoogilise teguri tõttu lihtsam taastada. Suurte mänguasjaharudega töötades võitleb teie kallutatud kallutatus teie ratsionaalse otsuse vastu. Te ei taha või isegi kardate sellist kogust koodi taastada.

“Parem proovida ja parandada. Parandus on koodi hulgaga võrreldes minimaalne. Pärast kogu tehtud tööd pole vaja kõike tagasi pöörata. ”- Kas need sõnad kõlavad teile tuttavalt?

Lõpuks peaksid väikesed ülesanded olema piisavalt väikesed, et üks meeskonnaliige saaks vähemalt korra päevas midagi meistriks liita.

Optimeerige paralleelseks arenguks

Siin kohtub tarkvara kujundamine tõesti pideva integreerimisega.

Isegi eraldiseisvate funktsionaalharude kallal töötades saavad meeskonnaliikmed üksteist blokeerida, kui nad ei jaga funktsiooni arendamist piisavalt hoolikalt.

On irooniline, et me kavandame oma tarkvara lahti siduda ja moodulid üksteisest sõltumatuks, samas kui meie arendusprotsessi kavandamine jätab palju soovida.

Nii näeb välja ühe funktsiooni arendusülesannete tüüpiline ajajaotus.

Guybrush peab alati ootama, millal Elaine oma ülesande lõpetab, vastasel juhul ei saa ta oma tööd tegema hakata. Stan on ummikus, kuni LeChuck ja Elaine tarnivad oma osad ning LeChuckil jääb lõpuks ainult üks ülesanne.

Kahjuks puudub hõbekuule funktsiooni arendamiseks, nii et iga meeskonna liige saaks paralleelselt töötada ka mõne ülesandega.

Mis siin kindlasti aitab, on vaadata funktsiooni tarkvara kujundamise vaatenurgast ja proovida aru saada, kus on lõigatud jooned. Põhimõtteliselt räägin ma enne ühiste piirkondade arendamise alustamist liideste otsimisest.

Kasulik heuristika on näiteks see, et kui kaks arendajat peavad töötama kahel külgneval alal, oletame näiteks esikülje komponendi ja selle taustapildi, saavad nad eelnevalt kokku leppida liideses, mida nad kavatsevad kasutada kahe osa suhtlemiseks.

Teine meeskond võiks selle asemel rakendada „kes saabub, see otsustab liidesereegli”, kus kaks või enam arendajat alustavad iseseisvat tööd ja esimene, kes saabub kontaktpunkti määratlemisel, täpsustab seda.

Asju saab ikkagi muuta, kui teised sinna jõuavad ja näevad, et määratlus ei sobi nende kasutustingimustega ideaalselt. Kuid vähemalt pole keegi vahepeal blokeeritud ja liidese parendamise vajadus õhutab tõenäoliselt tervislikku vestlust meeskonnaliikmete vahel ning huvitavaid teadmisi funktsiooni kujundamisel.

Järeldus

Pidev integreerimine ei tähenda teie tööriista.

Pidev integreerimine seisneb selles, kuidas oma arendusprotsessi inseneriks kujundada.

Selle sujuvaks toimimiseks on vaja aega ja vaeva.

See hõlmab erinevate sünkroonimisstrateegiate mõistmist ja rakendamist mitte ainult meeskonnaliikmete, vaid iga funktsiooni väljatöötamisse kaasatud inimese seas.

Kui lubate, et teie kohustust kontrollitakse testimise automatiseerimise torujuhtme suhtes, on kõigest kirss peal.