Azter dezagun zergatik diren CI tresnak eta CI gauza guztiz desberdinak.
Zer mina konpondu nahi duen CIk, nondik sortu zen ideia, zeintzuk dira funtzionatzen duen azken baieztapenak, nola ulertu praktika bat duzula eta ez Jenkins instalatu besterik ez duzula.
Etengabeko Integrazioari buruzko erreportaje bat egiteko ideia duela urtebete agertu zen, elkarrizketetara joan eta lan bila nengoela. 10-15 enpresarekin hitz egin nuen, haietako bakarrak argi eta garbi erantzun zidan CI zer den eta azaldu nola konturatu ziren ez zutela. Gainerakoek Jenkins-i buruz zentzugabekeria ulertezinak egiten ari ziren :) Beno, Jenkins dugu, eraikitzen du, CI! Txostenean zehar, Etengabeko Integrazioa benetan zer den azaltzen saiatuko naiz eta zergatik Jenkinsek eta antzeko tresnek harreman oso ahula duten honekin.
Beraz, zer etortzen zait burura normalean CI hitza entzutean? Jenkins, Gitlab CI, Travis, etab. pentsatuko du jende gehienak.
Googlen bilatu arren, tresna hauek emango dizkigu.
Galdetzen ezagutzen baduzu, tresnak zerrendatu ondoren berehala esango dizute CI dela probak eraikitzen eta exekutatzen dituzun konpromezu baterako Pull Request batean.
Etengabeko Integrazioa ez da erremintei buruz, ez adar batean probak dituzten muntaiak! Etengabeko Integrazioa kode berrien integrazio oso maiz egiten den praktika da eta hura erabiltzeko ez da batere beharrezkoa Jenkins, GitLab, etab.
CI osoa nolakoa den jakin baino lehen, murgil gaitezen sortu zuten pertsonen testuinguruan eta senti dezagun konpontzen saiatzen ari ziren mina.
Eta taldean elkarrekin lan egitearen mina konpondu zuten!
Ikus ditzagun taldeetan garatzeko garatzaileek dituzten zailtasunen adibideak. Hemen proiektu bat, git-en adar maisu bat eta bi garatzaile ditugu.
Eta lanera joan ziren denak aspaldian ohituta zeuden bezala. Gauzen eskema handian zeregin bat hartu genuen, ezaugarri adar bat sortu eta kodea idatzi genuen.
Batek funtzioa azkarrago amaitu zuen eta maisuan batu zuen.
Bigarrenak denbora gehiago behar izan zuen, geroago batu eta gatazka batekin amaitu zen. Orain, negozioak behar dituen ezaugarriak idatzi beharrean, garatzaileak bere denbora eta energia gastatzen ditu gatazkak konpontzen.
Zenbat eta zailagoa izan zure funtzioa maisu komun batekin konbinatzea, orduan eta denbora gehiago ematen dugu horretan. Eta adibide nahiko sinple batekin erakutsi nuen. Hau 2 garatzaile bakarrik dauden adibide bat da. Imajinatu enpresa bateko 10 edo 15 edo 100 pertsonak biltegi batera idazten badute. Zoratu egingo zara gatazka hauek guztiak konpontzeko.
Kasu apur bat desberdina da. Maisu bat eta garatzaile batzuk ditugu zerbait egiten.
Adar bat sortu zuten.
Bat hil zen, dena ondo zegoen, zeregina gainditu zuen.
Bigarren garatzaileak, berriz, bere zeregina eman zuen. Demagun berrikustera bidali duela. Enpresa askok berrikuspena izeneko praktika dute. Alde batetik, praktika hau ona eta erabilgarria da, bestetik, modu askotan moteltzen gaitu. Ez gara horretan sartuko, baina hona hemen berrikuspen istorio txar batek ekar dezakeenaren adibide bikaina. Berrikusteko eskaera bat bidali duzu. Garatzaileak ez du ezer gehiago egin. Zer egiten hasten da? Beste zeregin batzuk hartzen hasten da.
Denbora horretan, bigarren garatzaileak beste zerbait egin zuen.
Lehenengoak hirugarren zeregina bete zuen.
Eta denbora luze baten ondoren, bere berrikuspena probatu zen, eta hitz egiten saiatzen ari da. Beraz, zer gertatzen da? Gatazka ugari harrapatzen ditu. Zergatik? Bere tira eskaera berrikuspenean zintzilik zegoen bitartean, dagoeneko gauza asko aldatu ziren kodean.
Gatazkak dituen istorioaz gain, komunikazioak dituen istorio bat ere badago. Zure haria berrikuspenean zintzilik dagoen bitartean, zerbaiten zain dagoen bitartean, eginbide batean denbora luzez lanean ari zaren bitartean, zure zerbitzuaren kode-oinarrian aldatzen ari dena jarraitzeari uzten diozu. Beharbada, orain konpontzen saiatzen ari zarena atzo konpondu zen eta metodoren bat hartu eta berrerabili dezakezu. Baina hori ez duzu ikusiko beti zaharkitutako adar batekin lanean ari zarelako. Eta zaharkitutako adar honek beti eragiten du bateratze-gatazka bat konpondu behar izatea.
Bihurtzen da taldean lan egiten badugu, hau da, pertsona bat ez da biltegian ibiltzen, 5-10 pertsona baizik, orduan eta gehiago ez dugu gure kodea gehitzen maisuari, orduan eta gehiago sufritzen dugu, azkenean, behar dugulako. zerbait gero batu. Eta zenbat eta gatazka gehiago izan, eta zenbat eta bertsio zaharragoarekin lan egin, orduan eta arazo gehiago ditugu.
Zerbait elkarrekin egitea mingarria da! Beti oztopatzen dugu elkarri.
Arazo hau duela 20 urte baino gehiago nabaritu zen. Muturreko Programazioan Etengabeko Integrazioaren praktikaren lehen aipamena aurkitu dut.
Extreme Programming lehen marko arina da. Orria 96an agertu zen. Eta programazio praktikak, plangintza eta bestelakoak erabiltzea zen ideia, garapena ahalik eta malguena izan zedin, gure bezeroen aldaketa edo eskakizunei azkar erantzun ahal izateko. Eta duela 24 urte hasi ziren horri aurre egiten, oso denbora luzez eta alboan zerbait egiten baduzu, orduan denbora gehiago ematen duzula gatazkak dituzulako.
Orain "Etengabeko Integrazioa" esaldia banan-banan aztertuko dugu. Zuzenean itzultzen badugu, etengabeko integrazioa lortzen dugu. Baina nola jarraitua den ez dago oso argi; oso etena da. Baina zenbat integrazio duen ere ez da oso agerikoa.
Eta horregatik orain Extreme Programming-en aipamenak ematen dizkizut. Eta bi hitzak bereiz aztertuko ditugu.
Integrazioa - Lehen esan dudan bezala, ingeniari bakoitzak kodearen bertsiorik berrienarekin lan egiten duela ziurtatzen saiatzen gara, bere kodea adar komun batean ahalik eta gehien gehitzen ahalegin dadin, hauek adar txikiak izan daitezen. Handiak badira, erraz trabatu gaitezke bateratze-gatazkak astebetez. Hau bereziki egia da garapen-ziklo luzea badugu, esate baterako, ur-jauzia, non garatzailea hilabetez joan zen funtzio handi batzuk mozteko. Eta oso denbora luzez geratuko da integrazio fasean.
Integrazioa da gure adarra hartu eta maisuarekin integratzen dugunean, batu egiten dugu. Azken aukera bat dago transbase garatzaile bat garenean, non ahalegintzen gara maisuari berehala idazten diogula adar gehigarririk gabe.
Oro har, integrazioak zure kodea hartu eta maisuan arrastatzea esan nahi du.
Zer esan nahi da hemen “etengabe” hitzarekin, jarraitutasuna deitzen dena? Praktikak esan nahi du garatzaileak bere kodea ahalik eta azkarren integratzen ahalegintzen dela. Hau da bere helburua edozein zeregin burutzean: bere kodea ahalik eta azkarren maisuan sartzea. Mundu ideal batean, garatzaileek ordu gutxiro egingo lukete hori. Hau da, arazo txiki bat hartu eta maisuan batzen duzu. Dena bikaina da. Hau da ahalegintzen zarena. Eta hau etengabe egin behar da. Zerbait egin bezain laster, berehala sartzen duzu maisuan.
Eta zerbait egiten duen garatzailea da egin zuenaren arduraduna funtziona dezan eta ezer hausteko. Hemen agertzen da normalean probako istorioa. Proba batzuk egin nahi ditugu gure konpromisoan, gure batzean, funtzionatzen duela ziurtatzeko. Eta hemen Jenkinsek lagun zaitzake.
Baina istorioekin: egin ditzagun aldaketak txikiak, utz ditzagun zereginak txikiak izan, sortu gaitezen arazo bat eta saiatu berehala nolabait maisuan txertatzen - Jenkinsek ez du lagunduko hemen. Jenkinsek probak egiten bakarrik lagunduko dizulako.
Haiek gabe egin dezakezu. Horrek ez dizu batere minik egingo. Praktikaren helburua ahalik eta gehien neurtzea baita, etorkizunean gatazkarik gabe denbora asko galtzeko.
Imajina dezagun arrazoiren batengatik 2020an Internetik gabe gaudela. Eta lokalean lan egiten dugu. Ez dugu Jenkins. Hau ondo dago. Oraindik aurrera egin dezakezu eta tokiko sukurtsal bat egin dezakezu. Kode batzuk idatzi dituzu bertan. 3-4 ordutan amaitu dugu zeregina. Masterrera aldatu, git pull bat egin eta gure adarra batu genuen bertan. Prest. Askotan egiten baduzu, zorionak, Etengabeko Integrazioa duzu!
Zein froga dago mundu modernoan energia gastatzea merezi duela? Orokorrean zaila delako. Horrela lan egiten saiatzen bazara, ulertuko duzu orain plangintzaren bat eragingo duela, denbora gehiago eskaini beharko diozu zereginen deskonposizioari. Izan ere, gizona egiten baduzu..., orduan ezin izango zara azkar adostu eta, horren arabera, arazoak izango dituzu. Jada ez duzu praktikarik izango.
Eta garestia izango da. Ezin izango da berehala lan egin bihartik aurrera Etengabeko Integrazioa erabiliz. Oso denbora luzea beharko duzu denok ohitzeko, oso denbora luzea beharko duzu deskonposaketa atazaetara ohitzeko, oso denbora luzea beharko da berrikuspen praktika berriz egiten ohitzeko, baldin baduzu . Gure helburua gaur urtzea delako. Eta hiru eguneko epean berrikuspena egiten baduzu, orduan arazoak dituzu eta Etengabeko Integrazioa ez zaizu funtzionatzen.
Baina ba al dugu oraintxe bertan praktika horretan inbertitzeak zentzua duela esaten digun froga garrantzitsurik?
Burura etorri zitzaidan lehenengo gauza State of DevOps izan zen. Hau mutilek 7 urte daramatzaten ikerketa bat da. Orain erakunde independente gisa egiten dute, baina Googleren menpe.
Eta 2018ko ikerketak erakutsi zuen iraupen laburreko sukurtsalak erabiltzen saiatzen diren enpresen arteko korrelazioa, azkar integratzen direnak, maiz integratzen direnak eta IT errendimendu-adierazle hobeak dituztenak.
Zeintzuk dira adierazle horiek? Hauek dira galdera-sortetan enpresa guztiengandik hartzen dituzten 4 neurketak: zabaltze-maiztasuna, aldaketen denbora, zerbitzua berrezartzeko denbora, aldaketen porrot-tasa.
Eta, lehenik, korrelazio hori dago, badakigu maiz neurtzen duten enpresek neurri askoz hobeak dituztela. Eta enpresen banaketa hainbat kategoriatan dute: poliki-poliki zerbait ekoizten duten enpresa motelak dira, errendimendu ertainekoak, errendimendu handikoak eta elitekoak. Elitea Netflix, Amazon dira, oso azkarrak, dena azkar, ederki eta eraginkortasunez egiten dute.
Bigarren istorioa, duela hilabete besterik gertatu zena. Technology Radarrek Gitflow-i buruzko artikulu bikaina du. Gitflow beste guztien aldean desberdina da bere adarrak bizi luzeak direlako. Aspaldiko adarrak daude denbora luzez bizi direnak, eta denbora luzez bizi diren adarrak ere agertzen dira. Technology Radar-en praktika hau HOLD-era pasa da. Zergatik? Jendeak integrazioaren mina jasaten duelako.
Zure adarra oso denbora luzez bizi bada, trabatu egiten da, usteltzen da eta denbora gehiago ematen hasten gara aldaketaren bat egin nahian.
Eta duela gutxi Gitflow-en egileak esan zuen zure helburua Etengabeko Integrazioa bada, zure helburua ahalik eta sarritan jaurti nahi baduzu, orduan Gitflow ideia txarra da. Bereiz gehitu zuen artikuluan: hori lortzeko backend bat baduzu, Gitflow soberan dago zuretzat, Gitflow moteldu egingo zaituelako, Gitflow-ek arazoak sortuko dizkizula integrazioarekin.
Horrek ez du esan nahi Gitflow txarra denik eta erabili behar ez denik. Beste aldi batzuetarako da. Adibidez, zerbitzu edo aplikazio baten hainbat bertsio onartu behar dituzunean, hau da, denbora luzez laguntza behar duzunean.
Baina horrelako zerbitzuak onartzen dituzten pertsonekin hitz egiten baduzu, min handia entzungo duzu bertsio hau 3.2 zela, duela 4 hilabete, baina konponketa hau ez zegoen bertan sartuta eta orain, egin ahal izateko, aldaketa mordoa egin behar dituzu. Eta orain berriro itsatsita daude, eta orain astebete daramatzate funtzio berriren bat ezarri nahian.
Alexander Kovalevek txatean behar bezala adierazi zuenez, korrelazioa ez da kausalitatearen berdina. Hau egia da. Hau da, ez dago konexio zuzenik Integrazio jarraitua baduzu, metrika guztiak bikainak izango direla. Baina korrelazio positiboa dago: bata bat bada, ziurrenik bestea ere izango da. Ez da egia, baina ziurrenik. Korrelazio bat besterik ez da.
Badirudi dagoeneko zerbait egiten ari garela, badirudi dagoeneko bat egiten ari garela, baina nola ulertu oraindik Integrazio Etengabea dugula, sarritan bat egiten ari garela?
Jez Humble Handbook, Accelerate, Continuous Delivery webgunea eta Continuous Delivery liburuaren egilea da. Proba hau eskaintzen du:
- Ingeniariaren kodea egunero iristen zaio maisuari.
- Unitate-probak egiten dituzun konpromiso bakoitzeko.
- Masterreko eraikuntza erori egin zen, 10 minutu inguru konpondu zen.
Honelako proba bat erabiltzea proposatzen du, praktika nahikoa duzula ziurtatzeko.
Azken hau apur bat polemikoa iruditzen zait. Hau da, 10 minututan konpontzen baduzu, gero Integrazio Etengabea duzu, arraro samarra dirudi, nire ustez, baina zentzuzkoa da. Zergatik? Sarri izozten bazara, zure aldaketak txikiak direla esan nahi baitu. Aldaketa txiki batek zure eraikuntza nagusia hautsita dagoela esan nahi badu, adibide bat azkar aurki dezakezu aldaketa txikia delako. Hemen batuketa txiki bat izan zenuten, 20-30 lerro aldatu ziren. Eta, horren arabera, azkar uler dezakezu zein izan den arrazoia, aldaketak txikiak direlako, oso eremu txikia duzu arazoa bilatzeko.
Eta kaleratu ondoren gure akuilua apurtzen bada ere, Etengabeko Integrazioaren praktika baldin badugu, askoz errazagoa da jardutea, aldaketak txiki-txikiak direlako. Bai, horrek eragina izango du plangintzan. Horrek min egingo du. Eta, ziurrenik, praktika honetan zailena zereginak apurtzen ohitzea da, hau da, nola egin, zerbait hartu eta ordu gutxitan egin eta aldi berean errepaso bat pasatzeko, baldin eta bat daukazu. Berrikuspena aparteko mina da.
Unitate-probak zure integrazioa arrakastatsua izan den eta ezer hautsi ez den ulertzen laguntzen dizun laguntzaile bat besterik ez dira. Nire ustez, hori ere ez da guztiz derrigorrezkoa, hori ez baita praktikaren puntua.
Hau Etengabeko Integrazioari buruzko sarrera labur bat da. Hori da praktika honek duen guztia. Galderetarako prest nago.
Berriro laburbilduko dut:
- Etengabeko integrazioa ez da Jenkins, ez da Gitlab.
- Hau ez da tresna bat, gure kodea masterrean ahalik eta maiz batzen dugun praktika bat da.
- Etorkizunean bateratzeekin sortzen den min izugarria saihesteko egiten dugu hau, hau da, orain min pixka bat bizi dugu etorkizunean gehiago bizi ez izateko. Hori da kontua.
- Alboan kode bidezko komunikazioa dago, baina oso gutxitan ikusten dut hori, baina horretarako ere diseinatu zen.
Zure galderak
Zer egin deskonposatu gabeko zereginekin?
Deskonposatu. Zein da arazoa? Eman al dezakezu adibideren bat zeregin bat dagoela eta ez dagoela deskonposatu?
Badira “guztiz” hitzetik deskonposatu ezin diren zereginak, adibidez, esperientzia oso sakona eskatzen dutenak eta benetan hilabetean zehar konpon daitezkeenak emaitza digerigarriren bat lortzeko.
Ongi ulertzen badut, bada zeregin handi eta konplexu bat, eta horren emaitza hilabete batean bakarrik egongo da ikusgai?
Bai horixe. Bai, emaitza hilabete baino lehenago ebaluatu ahal izango da.
Ederki. Oro har, hau ez da arazo bat. Zergatik? Zeren kasu honetan, adarrei buruz hitz egiten dugunean, ez gara ezaugarri bat duen adarrez ari. Ezaugarriak handiak eta konplexuak izan daitezke. Osagai kopuru handi batean eragina izan dezakete. Eta agian ezin ditugu guztiz adar batean egin. Hau ondo dago. Istorio hau hautsi besterik ez dugu falta. Ezaugarri bat guztiz prest ez badago, horrek ez du esan nahi bere kodearen zati batzuk bateratu ezin direnik. Migrazioa gehitu duzu, esate baterako, eta funtzioaren barruan etapa batzuk daude. Demagun etapa bat duzula: egin migrazio bat, gehitu metodo berri bat. Eta gauza hauek egunero neur ditzakezu dagoeneko.
Ederki. Zein da orduan?
Zertarako balio du egunero gauza txikiak hiltzeak?
Bai.
Zerbait hausten badute, berehala ikusten duzu. Zerbait apurtu duen pieza txiki bat duzu, errazagoa da konpontzea. Kontua da orain pieza txiki bat batzea askoz errazagoa dela aste gutxitan zerbait handia batzea baino. Eta hirugarren puntua da beste ingeniari batzuek kodearen egungo bertsioarekin lan egingo dutela. Ikusiko dute hemen migrazio batzuk gehitu direla, eta gero, haiek ere erabili nahi duten metodoren bat agertu da. Denek ikusiko dute zer gertatzen den zure kodean. Hiru gauza horietarako egiten da praktika.
Eskerrik asko, gaia itxita dago!
(Oleg Soroka) Gehi dezaket? Dena ondo esan duzu, esaldi bat gehitu nahi dut.
Hortaz
Etengabeko integrazioarekin, kodea adar komun batean batzen da ez funtzioa guztiz prest dagoenean, baizik eta eraikuntza apurtzeari uzten dionean. Eta egunean nahi adina aldiz menperatzeko konpromisoa hartu dezakezu. Bigarren alderdia zera da: arrazoiren batengatik ezin baduzu hileko zeregina gutxienez hiru egunetan zatitu, hiru ordu inguru isilik nagoela, orduan arazo handi bat duzu. Eta Etengabeko Integraziorik ez izatea da arazo horietako txikiena. Horrek esan nahi du arazoak dituzula arkitekturarekin eta zero ingeniaritza praktikarekin. Zeren eta hau ikerketa bada ere, edonola ere hipotesi edo ziklo moduan formulatu behar da.
Enpresa arrakastatsuak atzeratutakoetatik bereizten dituzten 4 neurketari buruz hitz egin dugu. Oraindik bizi behar dugu 4 metrika hauek ikusteko. Zure batez besteko zereginak hilabete bat behar badu burutzeko, orduan zentratuko nintzateke metrika honetan lehenik. Lehenengo 3 egunetara jaitsiko nuke. Eta horren ostean Etengabean pentsatzen hasi nintzen.
Ondo ulertu al dizut uste duzula, oro har, ez duela zentzurik ingeniaritza praktiketan inbertitzeak edozein zeregin burutzeko hilabete behar badu?
Etengabeko Integrazioa duzu. Eta badago gai bat, 10 minututan konponketa bat konpondu edo atzera bota dezakezula. Imajinatu atera duzula. Gainera, etengabeko inplementazioa ere baduzu, prod atera zenuen eta orduan bakarrik ohartu zara zerbait gaizki joan zela. Eta atzera egin behar duzu, baina dagoeneko zure datu-basea migratu duzu. Dagoeneko duzu hurrengo bertsioaren datu-basearen eskema, gainera, nolabaiteko babeskopia ere bazenuen, eta datuak ere bertan idatzi ziren.
Eta zer alternatiba duzu? Kodea atzera egiten baduzu, jada ezingo du funtzionatu datu-base eguneratu honekin.
Oinarria aurrera baino ez da egiten, bai.
Ingeniaritza praktika eskasak dituzten pertsonek, ziurrenik, ez dute irakurri... buruzko liburu lodia ere. Zer egin babeskopiarekin? Babeskopia batetik leheneratzen baduzu, esan nahi du une horretan pilatutako datuak galtzen dituzula. Adibidez, hiru orduz lan egin genuen datu-basearen bertsio berriarekin, erabiltzaileak bertan erregistratuta. Babeskopia zaharrari uko egiten diozu eskemak ez duelako funtzionatzen bertsio berriarekin, beraz, erabiltzaile hauek galdu dituzu. Eta konforme daude, zin egiten dute.
Etengabeko Integrazioa eta Etengabeko Bidalketa onartzen duten praktika sorta osoa menderatzeko, ez da nahikoa idazten ikastea... Lehenik eta behin, asko egon daitezke, ez da praktikoa izango. Gainera, zientzia bezalako beste praktika ugari daude. Halako praktika bat dago, GitHub-ek garai batean ezagun egin zuen. Hau da, kode zaharra eta kode berria aldi berean exekutatzen dituzunean. Hau da amaitu gabeko eginbide bat egiten duzunean, baina balioren bat itzul dezake: funtzio gisa edo Rest API gisa. Kode berria eta kode zaharra exekutatzen dituzu, eta haien arteko aldea konparatu. Eta aldea badago, gertaera hau erregistratuko duzu. Horrela jakingo duzu funtzio berri bat prest duzula zaharraren gainean zabaltzeko, denbora jakin batean bien artean desadostasunik izan ez baduzu.
Horrelako praktikak ehunka daude. Transbase garapenarekin hastea proposatuko nuke. Ez dago %100ean Etengabeko Integrazioan, baina praktikak berdinak dira, bata ezin da ondo bizi bestea gabe.
Praktikak ikus ditzakezun adibide gisa transbase garapena jarri duzu edo jendeari transbase debelopment erabiltzen hastea iradokitzen diozu?
Begiratu, ezin izango dutelako erabili. Horiek erabiltzeko, asko irakurri behar da. Eta pertsona batek galdetzen duenean: "Zer egin hilabete behar duen funtzio batekin, esan nahi du ez duela transbase garapenari buruz irakurri". Ez nuke gomendatuko oraindik. Zeregin handiak txikiagotan arkitekturaki zuzen nola zatitu gaian soilik zentratzea gomendatuko nuke. Hau da deskonposizioaren funtsa.
Deskonposizioa da arkitektoaren tresnetako bat. Lehenik analisia egiten dugu, gero deskonposizioa, gero sintesia, gero integrazioa. Eta horrela funtzionatzen digu dena. Eta oraindik deskonposizioaren bidez etengabeko integraziora hazi behar dugu. Lehenengo etapan galderak sortzen dira, eta dagoeneko laugarren etapaz ari gara, hau da, zenbat eta maizago egin integrazioa, hobeto. Oraindik goiz da hau egiteko; ona litzateke lehenik monolitoa moztea.
Diagrama batzuetan gezi eta karratu batzuk marraztu behar dituzu. Ezin duzu esan orain aplikazio berri baten eskema arkitektonikoa erakutsiko dudanik eta karratu bat erakutsiko dudala, eta horren barruan aplikaziorako botoi berde bat dago. Nolanahi ere, lauki eta gezi gehiago egongo dira. Ikusi nuen diagrama bakoitzak bat baino gehiago zituen. Eta deskonposizioa, nahiz eta irudikapen grafikoaren mailan, gertatzen ari da jada. Beraz, karratuak independenteak izan daitezke. Hala ez bada, orduan galdera handiak dauzkat arkitektoarentzat.
Txatean galdera bat dago: "Iritzia derrigorrezkoa bada eta denbora luzea hartzen badu, agian egun bat edo gehiago?"
Arazoak dituzu praktikarekin. Berrikuspenak ez luke egun bat edo gehiago iraun behar. Hau aurreko galderaren istorio bera da, apur bat leunagoa bakarrik. Berrikuspen bat egun batez egiten bada, ziurrenik berrikuspen hau oso aldaketa handia izango da. Horrek esan nahi du txikiagoa egin behar dela. Transbase garapenean, Oleg-ek gomendatzen zuena, etengabeko berrikuspena izeneko istorio bat dago. Bere ideia da nahita egiten dugula halako tira eskaera txiki bat, etengabe eta pixkanaka bat egiten ahalegintzen garelako. Beraz, tira eskaerak abstrakzio bat edo 10 lerro aldatzen ditu. Berrikuspen honi esker, pare bat minutu behar ditugu.
Berrikuspenak egun bat edo gehiago irauten badu, zerbait gaizki dago. Lehenik eta behin, arkitekturarekin arazo batzuk izan ditzakezu. Edo hau kode handi bat da, 1 lerro, adibidez. Edo zure arkitektura hain konplexua da, non pertsona batek ezin duela ulertu. Hau apur bat alboko arazoa da, baina konpondu beharko da ere. Agian ez dago batere berrikuspenik behar. Hau ere pentsatu behar dugu. Berrikuspena moteltzen zaituen gauza da. Bere abantailak ditu orokorrean, baina ulertu behar duzu zergatik egiten duzun. Informazioa azkar helarazteko modu bat al da, barnean estandar batzuk ezartzeko modu bat al da edo zer? Zergatik behar duzu hau? Berrikuspena oso azkar edo erabat bertan behera utzi behar delako. Transbase development bezalakoa da: istorioa oso polita da, baina helduentzat bakarrik.
4 neurketei dagokienez, oraindik kentzea gomendatuko nuke horrek zertara ekartzen duen ulertzeko. Begira zenbakiak, begiratu argazkia, zein txarra den dena.
(Dmitry) Prest nago zurekin honi buruzko eztabaidan sartzeko. Zenbakiak eta neurketak bikainak dira, praktikak bikainak. Baina negozioak behar duen ala ez ulertu behar duzu. Badaude aldaketa horren abiadura behar ez duten negozioak. Badakit 15 minuturo aldaketarik egin ezin duten enpresak. Eta ez hain txarrak direlako. Hau da halako bizi-ziklo bat. Eta adarrak egiteko, txandakatzeko funtzioa, ezagutza sakona behar duzu.
Zaila da. Toggle funtzioari buruzko istorioa zehatzago irakurri nahi baduzu, gomendatzen dizut . Eta Martin Fowler-en artikulu zoragarri bat dago txandakatzeko funtzioei buruz: zer mota dauden, bizi-zikloak, etab. Toggle funtzioa konplikatua da.
Eta oraindik ez diozu galderari erantzun: "Jenkins behar al da ala ez?"
Jenkins ez da inola ere behar benetan. Benetan, tresnak: Jenkins, Gitlab-ek erosotasuna ekarriko dizu. Ikusiko duzu muntaia muntatuta dagoela edo muntatuta ez dagoela. Lagun zaitzakete, baina ez dizute praktikarik emango. Zirkulu bat baino ezin dizute eman - Ados, Ados ez. Eta gero, probak ere idazten badituzu, probarik ez badago, ia alferrik da. Hori dela eta, beharrezkoa da erosoagoa delako, baina oro har gabe bizi zaitezke, ez duzu asko galduko.
Hau da, praktikak badituzu, horrek esan nahi du ez duzula behar?
Hori bai. Jez Humble proba gomendatzen dut. Hor daukat jarrera anbibalentea azken puntuarekiko. Baina, oro har, hiru gauza badituzu, etengabe batu egiten zara, probak egiten dituzu masterrean konpromisoetan, azkar konpontzen duzu eraikuntza maisuan, eta gero agian ez duzu beste ezer behar.
Parte-hartzaileen galderen zain gauden bitartean, galdera bat daukat. Produktu kodeari buruz ari ginen. Erabili al duzu azpiegitura kodearako? Kode bera al da, printzipio eta bizi-ziklo berdinak al ditu ala bizi-ziklo eta printzipio desberdinak daude? Normalean, denek Etengabeko Integrazioaz eta Garapenaz hitz egiten dutenean, denek ahazten dute azpiegitura kodea ere badela. Eta azkenaldian gero eta gehiago dago. Eta arau hauek guztiak ekarri behar al dira bertara?
Izan beharko lukeena ere ez, bikaina izango litzateke, bizitza erraztuko lukeelako era berean. Kodearekin lan egiten dugun bezain laster, ez bash scriptekin, baina kode normala dugu.
Gelditu, gelditu, bash script bat ere kodea da. Ez ukitu nire maitasun zaharra.
Ados, ez ditut zure oroitzapenak zapalduko. Ez dut bash-en gustuko. Itsusi eta beldurgarria hausten da denbora guztian. Eta askotan ezusteko apurtzen da, horregatik ez zait gustatzen. Baina ados, demagun bash kodea duzula. Agian ez dut ulertzen eta proba-esparru normalak daude hor. Ez nago jakitun. Eta onura berdinak lortzen ditugu.
Azpiegitura kode gisa lan egiten dugun bezain laster, garatzaileen arazo berdinak ditugu. Duela hilabete batzuk, lankide batek 1 lerro bash-en pull request bat bidali zidan egoera batekin topo egin nuen. Eta 000 orduz egoten zara berrikusketan. Arazo berdinak sortzen dira. Oraindik kodea da. Eta elkarlana da oraindik. Pull eskaerarekin trabatu egiten gara eta bash berean konpontzen ari garela bateratze gatazkak, adibidez.
Orain oso aktiboki ari naiz ikusten infraprogramazio ederrenean gauza hau guztia. Pulumi azpiegiturara ekarri dut orain. Hau programazioa da bere forma garbienean. Hor are politagoa da, programazio-lengoaia baten gaitasun guztiak ditudalako, hau da, txandakatze ederra egin nuen ifs berdinekin eta dena ondo dago. Hau da, nire aldaketa jada maisuan dago. Denek ikus dezakete jada. Beste ingeniari batzuek badakite. Dagoeneko zerbait eragin du hor. Hala ere, ez zegoen azpiegitura guztietarako gaituta. Nire proba-bankuetarako piztu zen, adibidez. Horregatik, zure galderari berriro erantzuteko, beharrezkoa da. Bizitza errazten digu modu berean, kodearekin lan egiten dugun ingeniariok.
Beste norbaitek galderarik badu?
Galdera bat daukat. Olegekin eztabaidan jarraitu nahi dut. Orokorrean, uste dut arrazoi duzuela, zeregin batek hilabete bat behar badu burutzeko, orduan arazo bat duzu arkitekturarekin, analisiarekin, deskonposizioarekin, planifikazioarekin, etab. Baina sentsazioa daukat hasten bazara. Etengabeko Integrazioaren arabera bizitzen saiatuz gero, plangintzarekin mina zuzentzen hasiko zara, ez zarelako beste inon alde egingo.
(Oleg) Bai, hori da. Praktika hau kultura aldatzeko beste edozein praktika seriorekin parekoa da. Gainditzen zailena ohiturak dira, batez ere ohitura txarrak. Eta praktika hori gauzatzeko, ingurukoen ohituretan aldaketa larria behar bada: garatzaileak, zuzendaritza, produkzio arduraduna, orduan sorpresak zain dituzu.
Zein sorpresa egon daitezke? Demagun sarriago integratuko zarela erabakitzen duzula. Eta beste gauza batzuk dituzu integrazioari lotuta, adibidez, artefaktuak. Eta zure enpresan, adibidez, artefaktu bakoitza nolabait artefaktuen biltegiratze-sistema batean kontabilizatu behar den politika dago. Eta denbora pixka bat behar da. Pertsona batek, kaleratze-kudeatzaile gisa, artefaktu hau probatu duen laukia egiaztatu behar du, ekoizpenean kaleratzeko prest dagoela ziurtatzeko. 5-10-15 minutu behar badituzu, baina diseinua astean behin egiten baduzu, orduan astean behin ordu erdi pasatzea zerga txikia da.
Egunean 10 aldiz etengabeko integrazioa egiten baduzu, orduan 10 aldiz 30 minutuz biderkatu behar dira. Eta horrek kaleratze-kudeatzaile honen lan-denbora gainditzen du. Hori egiteaz nekatu besterik ez da egiten. Praktika batzuetarako kostu finkoak daude. Hori da dena.
Eta arau hau bertan behera utzi behar duzu, zabor hori gehiago egin ez dezazun, hau da, ez duzu eskuz esleitu zerbaiti dagokion titulua. Prestakuntza-test automatiko batzuetan oinarritzen zara erabat.
Eta norbaiten froga behar baduzu, buruzagiak sina dezan, eta ez zara ekoizpenean sartu Vasyak baimentzen duela esan gabe, etab. - zentzugabekeria hori guztia praktikanteari oztopatzen zaio. Zerga batekin lotutako jarduera batzuk badaude, orduan dena 100 aldiz handitzen da. Hori dela eta, aldaketa askotan ez dute denek poztasunez agurtuko. Jendearen ohiturak aldatzea zaila delako.
Pertsona batek bere ohiko lana egiten duenean, ia pentsatu gabe egiten du. Bere karga kognitiboa zero da. Besterik gabe jolasten du, dagoeneko buruan dauka kontrol-zerrenda, mila aldiz egin du. Eta etorri eta esan orduko: «Utzi dezagun praktika hau eta aurkeztu berri bat astelehenetik aurrera», berarentzat karga kognitibo indartsua bihurtzen da. Eta guztiontzat dator aldi berean.
Hori dela eta, gauzarik sinpleena, nahiz eta denek ezin duten luxu hau ordaindu, baina hau da beti egiten dudana, hau da honako hau. Proiektu berri bat hasten bada, normalean probatu gabeko praktika guztiak berehala sartzen dira proiektu honetan. Proiektua gaztea den arren, ez dugu ezer arriskatzen. Oraindik ez dago Prod, ez dago ezer suntsitzeko. Hori dela eta, prestakuntza gisa erabil daiteke. Ikuspegi honek funtzionatzen du. Baina enpresa guztiek ez dute horrelako proiektuak askotan hasteko aukera. Hau ere pixka bat arraroa bada ere, orain eraldaketa digital osoa dagoelako, denek esperimentuak jarri behar dituzte martxan lehiakideekin jarraitzeko.
Hemen, lehenik eta behin, zer egin behar duzun ulertu behar duzula ondorioztatzen duzu. Mundua ez da ideala, eta prod ere ez da ideala.
Bai, gauza hauek elkarrekin lotuta daude.
Enpresek ere ez dute beti ulertzen bide horretatik jo behar dutenik.
Badago egoera bat, aldaketarik ez dagoenean. Taldean presio handiagoa dagoen egoera da. Taldea nahiko erreta dago jada. Ez du denbora librerik esperimentuetarako. Goizetik arratsaldera funtzioak lantzen dituzte. Eta kudeaketak gero eta ezaugarri gutxiago ditu. Gero eta gehiago behar dira. Egoera horretan, ezin da aldaketarik egin. Bihar atzoko berdina egingo dugula esan besterik ez dago taldeari, ezaugarri apur bat gehiago egin besterik ez dugu falta. Zentzu honetan, ez da posible inongo praktikarako trantsiziorik. Egoera klasikoa da aizkora zorrozteko denborarik ez dagoenean, zuhaitzak moztu behar dira, beraz, aizkora makur batekin mozten dute. Hemen ez dago aholku sinplerik.
(Dmitry) Txat-etik argipen bat irakurriko dut: "Baina maila ezberdinetan proba-estaldura asko behar dugu. Zenbat denbora ematen da probetarako? Pixka bat garestia da eta denbora asko eskatzen du».
(Oleg) Hau uste oker klasikoa da. Konfiantza izateko nahikoa proba egon beharko lirateke. Etengabeko Integrazioa ez da proben % 100 lehenik egiten den gauza bat eta gero praktika hau aplikatzen hasten zara. Etengabeko integrazioak zure karga kognitiboa murrizten du, begiekin ikusten dituzun aldaketa bakoitza hain begi-bistakoa delako ulertzen duzulako zerbait hautsiko duen ala ez, probarik egin gabe ere. Azkar proba dezakezu zure buruan aldaketak txikiak direlako. Eskuzko probatzaileak bakarrik badituzu ere, haientzat ere errazagoa da. Atera eta esan zenuen: "Begira, zerbait hautsita al dago?" Egiaztatu eta esan zuten: "Ez, ez dago ezer hautsi". Probatzaileak badakielako nora begiratu. Konpromiso bat duzu kode zati batekin lotuta. Eta hori portaera zehatz baten bidez baliatzen da.
Hemen zu, noski, apainduta.
(Dmitry) Ez nago ados hemen. Praktika bat dago: probak gidatutako garapena, honetatik salbatuko zaituena.
(Oleg) Beno, oraindik ez naiz puntu horretara iritsi. Lehenengo ilusioa da proben % 100 idatzi behar duzula edo ez duzula Etengabeko Integraziorik egin behar. Ez da egia. Bi praktika paralelo dira. Eta ez dira zuzenean menpekoak. Zure probaren estaldura optimoa izan behar da. Optimoa - horrek esan nahi du zuk zeuk ziur zaudela zure maisuak konpromisoaren ondoren geratu den maisuaren kalitateak mozkortutako ostiral arratsalde batean "Inplementatu" botoia konfiantzaz sakatzea ahalbidetzen duela. Nola lortzen duzu hori? Berrikuspenaren bidez, estalduraren bidez, jarraipen onaren bidez.
Jarraipen ona ez da probetan bereizten. Preprodukzioan behin probak egiten badituzu, orduan zure erabiltzaile-script guztiak egiaztatzen dituzte behin eta kito. Eta begizta amaigabean exekutatzen badituzu, hau da inplementatutako monitorizazio-sistema, dena etengabe probatzen duena, huts egin den ala ez. Kasu honetan, alde bakarra behin edo bitan egiten den da. Proba multzo oso ona... etengabe exekutatzen, hau monitorizazioa da. Eta jarraipen egokiak horrela izan beharko luke.
Eta, beraz, nola lortuko duzun egoera hori ostiral arratsaldean prestatu eta etxera joaten zarenean beste galdera bat da. Beharbada, zoro ausart bat besterik ez zara.
Atzera egin dezagun pixka bat Etengabeko Integraziora. Praktika konplexu apur bat ezberdin batera ihes egin genuen.
Eta bigarren ilusioa da MVP, esaten dutenez, azkar egin behar dela, beraz, probak ez dira batere behar. Ez zalantzarik modu horretan. Kontua da MVP batean erabiltzaile-istorio bat idazten duzunean, edo pilotan garatu dezakezula, hau da, erabiltzaile-istorio bat zegoela entzun eta berehala kodetzera korrika egin dezakezula, edo TDD erabiliz lan egin dezakezula. Eta TDDren arabera, praktikak erakusten duen moduan, ez da denbora gehiago behar, hau da, probak bigarren mailako efektua dira. TDD praktika ez da probatzea. Test Driven Development deitzen den arren, ez da batere probei buruz. Hau ere ikuspegi arkitektoniko bat da. Hau behar dena zehatz-mehatz idazteko eta behar ez dena ez idazteko hurbilketa bat da. Aplikazio-arkitektura bat sortzeari dagokionez, zure pentsamenduaren hurrengo iterazioan zentratzeko praktika bat da.
Horregatik, ez da hain erraza ilusio horiek kentzea. MVP eta probak ez dira elkarren aurka egiten. Nahiz eta, aitzitik, TDD praktika erabiliz MVP egiten baduzu, orduan hobeto eta azkarrago egingo duzu batere entrenamendurik gabe, baina baloiarekin egiten baduzu baino.
Oso ideia ez-agerikoa eta konplexua da. Orain proba gehiago idatziko ditudala entzuten duzunean eta aldi berean zerbait azkarrago egingo dudala, guztiz desegokia dirudi.
(Dmitry) Hemen jende askok, MVP deitzen dutenean, jendea alferra da zerbait normala idazteko. Eta hauek oraindik gauza desberdinak dira. Ez dago MVP funtzionatzen ez duen gauza txar batean bihurtu beharrik.
Bai, bai, arrazoi duzu.
Eta gero bat-batean MVP prod.
Betirako.
Eta TDDk oso ezohikoa dirudi probak idazten dituzula eta lan gehiago egiten duzula entzuten duzunean. Oso arraroa dirudi, baina egia esan azkarrago eta politagoa ateratzen da horrela. Proba bat idazten duzunean, buruan asko pentsatzen duzu zer kodea eta nola deituko den, baita bertatik espero dugun portaera ere. Ez duzu esan funtzioren bat idatzi dudala eta zerbait egiten duela. Hasieran uste zenuen halako eta halako baldintzak zituela, halako batean deituko zela. Hau probez estaltzen duzu eta hortik ulertzen duzu zure interfazeak zure kodearen barruan nola ikusiko diren. Horrek eragin handia du arkitekturan. Zure kodea automatikoki modularagoa bihurtzen da, lehenik eta behin nola probatuko duzun ulertzen saiatzen zarelako eta gero idazten.
TDDrekin gertatu zitzaidana izan zen, noizbait Rubyko tutore bat kontratatu nuela oraindik Ruby programatzailea nintzela. Eta esaten du: "Egin dezagun TDDren arabera". Pentsatu nuen: "Maioa, orain zerbait gehigarria idatzi behar dut". Eta adostu genuen bi aste barru lan-kode guztia idatziko nuela Python-en TDD erabiliz. Bi asteren buruan, konturatu nintzen ez nuela itzuli nahi. Bi aste hau nonahi aplikatzen saiatu ondoren, konturatzen zara zein errazago bihurtu zaizun pentsatzea ere. Baina hori ez da begi-bistakoa, beraz, guztiei gomendatzen diet TDD zaila, denbora asko eta beharrezkoa ez dela iruditzen bazaizu, saia zaitezte bi astez besterik ez. Bi nahikoa ziren niretzat.
(Dmitry) Azpiegituren funtzionamenduaren ikuspuntutik zabaldu dezakegu ideia hau. Ezer berririk martxan jarri aurretik, jarraipena egiten dugu eta gero abiarazten dugu. Kasu honetan, monitorizazioa ohiko proba bihurtzen da guretzat. Eta jarraipenaren bidez garapena dago. Baina ia denek esaten dute luzea dela, alferra naiz, behin-behineko zirriborroa egin nuen. Jarraipen normala egin badugu, CI sistemaren egoera ulertzen dugu. Eta CI sistemak monitorizazio handia du. Sistemaren egoera ulertzen dugu, barruan zer dagoen ulertzen dugu. Eta garapenean, sistema egiten ari gara nahi den egoerara iristeko.
Praktika hauek aspalditik ezagutzen dira. Duela 4 urte inguru eztabaidatu genuen. Baina 4 urtean ez da ia ezer aldatu.
Baina ohar honetan, eztabaida ofizialari amaiera ematea proposatzen dut.
Bideoa (media-elementu gisa txertatua, baina arrazoiren batengatik ez du funtzionatzen):
Iturria: www.habr.com