Kom ons bespreek hoekom CI-gereedskap en CI heeltemal verskillende dinge is.
Watter pyn is CI bedoel om op te los, waar het die idee vandaan gekom, wat is die nuutste bevestigings dat dit werk, hoe om te verstaan dat jy 'n praktyk het en nie net Jenkins geïnstalleer het nie.
Die idee om 'n verslag oor Deurlopende integrasie te maak, het 'n jaar gelede verskyn toe ek vir onderhoude gegaan het en werk gesoek het. Ek het met 10-15 maatskappye gepraat, net een van hulle kon duidelik antwoord wat CI is en verduidelik hoe hulle besef het dat hulle dit nie het nie. Die res het onverstaanbare snert oor Jenkins gepraat :) Wel, ons het Jenkins, dit bou wel, CI! Tydens die verslag sal ek probeer verduidelik wat Deurlopende Integrasie eintlik is en waarom Jenkins en soortgelyke instrumente 'n baie swak verhouding hiermee het.
So, wat kom gewoonlik by jou op as jy die woord CI hoor? Die meeste mense sal aan Jenkins, Gitlab CI, Travis, ens.
Selfs as ons dit google, sal dit vir ons hierdie gereedskap gee.
As jy vertroud is om te vra, sal hulle onmiddellik na die lys van die gereedskap vir jou sê dat CI is wanneer jy toetse bou en uitvoer in 'n Pull Request for 'n commit.
Deurlopende integrasie gaan nie oor gereedskap nie, nie oor samestellings met toetse in 'n tak nie! Deurlopende integrasie is die praktyk van baie gereelde integrasie van nuwe kode en om dit te gebruik is dit glad nie nodig om Jenkins, GitLab, ens.
Voordat ons uitvind hoe 'n volwaardige CI lyk, kom ons duik eers in die konteks van die mense wat daarmee vorendag gekom het en voel die pyn wat hulle probeer oplos het.
En hulle het die pyn opgelos om as 'n span saam te werk!
Kom ons kyk na voorbeelde van die probleme wat ontwikkelaars ondervind wanneer hulle in spanne ontwikkel. Hier het ons 'n projek, 'n meestertak in git en twee ontwikkelaars.
En hulle het gaan werk soos almal lankal gewoond was. Ons het 'n taak in die groot skema van dinge geneem, 'n kenmerktak geskep en die kode geskryf.
Een het die kenmerk vinniger voltooi en dit in die meester saamgevoeg.
Die tweede een het meer tyd nodig gehad, dit het later saamgesmelt en op 'n konflik geëindig. Nou, in plaas daarvan om die kenmerke te skryf wat die besigheid benodig, spandeer die ontwikkelaar sy tyd en energie om konflikte op te los.
Hoe moeiliker dit is om jou kenmerk met 'n gemeenskaplike meester te kombineer, hoe meer tyd spandeer ons daaraan. En ek het dit met 'n redelik eenvoudige voorbeeld gewys. Dit is 'n voorbeeld waar daar net 2 ontwikkelaars is Stel jou voor as 10 of 15 of 100 mense in 'n maatskappy na een bewaarplek skryf. Jy sal mal word om al hierdie konflikte op te los.
Daar is 'n effens ander geval. Ons het 'n meester en 'n paar ontwikkelaars wat iets doen.
Hulle het 'n takkie geskep.
Een het gesterf, alles was reg, hy het die taak geslaag.
Die tweede ontwikkelaar het intussen sy taak ingehandig. Kom ons sê hy het dit vir hersiening gestuur. Baie maatskappye het 'n praktyk genaamd hersiening. Aan die een kant is hierdie praktyk goed en nuttig, aan die ander kant vertraag dit ons op baie maniere. Ons gaan nie daarop in nie, maar hier is 'n goeie voorbeeld van waartoe 'n slegte resensieverhaal kan lei. Jy het 'n trekversoek vir hersiening ingedien. Daar is niks meer vir die ontwikkelaar om te doen nie. Wat begin hy doen? Hy begin ander take aanneem.
Gedurende hierdie tyd het die tweede ontwikkelaar iets anders gedoen.
Die eerste een het die derde taak voltooi.
En na 'n lang tyd is sy resensie getoets, en hy probeer tot verhaal kom. So wat gaan aan? Dit vang 'n groot aantal konflikte op. Hoekom? Want terwyl sy trekversoek in die resensie gehang het, het baie dinge reeds in die kode verander.
Benewens die storie met konflikte, is daar 'n storie met kommunikasie. Terwyl jou draad aan hersiening hang, terwyl dit op iets wag, terwyl jy lank aan 'n kenmerk werk, hou jy op om na te spoor wat anders in die kodebasis van jou diens verander. Miskien is dit wat jy nou probeer oplos reeds gister opgelos en jy kan een of ander metode gebruik en dit hergebruik. Maar jy sal dit nie sien nie, want jy werk altyd met 'n verouderde tak. En hierdie verouderde tak lei altyd daartoe dat jy 'n samesmeltingskonflik moet oplos.
Dit blyk dat as ons as 'n span werk, d.w.s. nie een persoon soek in die bewaarplek nie, maar 5-10 mense, hoe langer ons nie ons kode by die meester voeg nie, hoe meer ly ons omdat ons uiteindelik nodig het iets, voeg dit dan saam. En hoe meer konflikte ons het, en hoe ouer weergawe ons mee werk, hoe meer probleme het ons.
Om iets saam te doen is pynlik! Ons staan altyd in mekaar se pad.
Hierdie probleem is meer as 20 jaar gelede opgemerk. Ek het die eerste melding gevind van die praktyk van deurlopende integrasie in ekstreme programmering.
Ekstreme programmering is die eerste ratse raamwerk. Die blad het in 96 verskyn. En die idee was om 'n soort programmeringspraktyke, beplanning en ander dinge te gebruik, sodat die ontwikkeling so buigsaam as moontlik sou wees, sodat ons vinnig kon reageer op enige veranderinge of vereistes van ons kliënte. En hulle het dit 24 jaar gelede begin in die gesig staar, dat as jy iets vir 'n baie lang tyd en op die kantlyn doen, dan spandeer jy meer tyd daaraan omdat jy konflikte het.
Nou sal ons die frase "Deurlopende integrasie" individueel ontleed. As ons dit direk vertaal, kry ons deurlopende integrasie. Maar hoe deurlopend dit is, is nie baie duidelik nie; Maar hoeveel integrasie dit het, is ook nie baie duidelik nie.
En dit is hoekom ek nou vir jou aanhalings uit Extreme Programming gee. En ons sal albei woorde afsonderlik ontleed.
Integrasie - Soos ek reeds gesê het, streef ons daarna om te verseker dat elke ingenieur werk met die nuutste weergawe van die kode, sodat hy daarna streef om sy kode so dikwels as moontlik by 'n gemeenskaplike tak te voeg, sodat dit klein takke is. Want as hulle groot is, dan kan ons maklik vir 'n week met samesmeltingskonflikte vashaak. Dit is veral waar as ons 'n lang ontwikkelingsiklus het, soos 'n waterval, waar die ontwikkelaar 'n maand lank weggegaan het om 'n groot kenmerk te sny. En hy sal vir baie lank by die integrasiestadium vassit.
Integrasie is wanneer ons ons tak neem en dit met die meester integreer, ons dit saamsmelt. Daar is 'n uiteindelike opsie wanneer ons 'n transbasis-ontwikkelaar is, waar ons daarna streef om te verseker dat ons dadelik aan die meester skryf sonder enige ekstra vertakkings.
Oor die algemeen beteken integrasie dat u u kode neem en dit na die meester sleep.
Wat word hier bedoel met die woord “kontinuïteit”, wat word kontinuïteit genoem? Praktyk impliseer dat die ontwikkelaar daarna streef om sy kode so vinnig as moontlik te integreer. Dit is sy doel wanneer hy enige taak uitvoer - om sy kode so vinnig as moontlik in meester te kry. In 'n ideale wêreld sal ontwikkelaars dit elke paar uur doen. Dit wil sê, jy neem 'n klein probleem en voeg dit saam in die meester. Alles is puik. Dit is waarna jy streef. En dit moet voortdurend gedoen word. Sodra jy iets doen, sit jy dit dadelik in die meester.
En die ontwikkelaar wat iets maak, is verantwoordelik vir wat hy gedoen het om dit te laat werk en niks te breek nie. Dit is waar die toetsverhaal gewoonlik uitkom. Ons wil 'n paar toetse uitvoer oor ons commit, op ons samesmelting, om seker te maak dat dit werk. En dit is waar Jenkins jou kan help.
Maar met stories: kom ons maak die veranderinge klein, kom ons laat die take klein wees, kom ons maak 'n probleem en probeer dadelik om dit op een of ander manier in die meester in te sluit - geen Jenkins sal hier help nie. Want Jenkins sal jou net help om toetse uit te voer.
Jy kan sonder hulle klaarkom. Dit sal jou glad nie seermaak nie. Omdat die doel van oefening is om so gereeld as moontlik te meet, om nie 'n groot hoeveelheid tyd op enige konflikte in die toekoms te mors nie.
Kom ons stel ons voor dat ons om een of ander rede in 2020 sonder die internet is. En ons werk plaaslik. Ons het nie Jenkins nie. Dit is goed. Jy kan steeds voortgaan en 'n plaaslike tak maak. Jy het 'n kode daarin geskryf. Ons het die taak in 3-4 uur voltooi. Ons het oorgeskakel na meester, 'n git pull gedoen en ons tak daar saamgevoeg. Gereed. As jy dit gereeld doen, baie geluk, jy het deurlopende integrasie!
Watter bewyse in die moderne wêreld is daar dat dit die moeite werd is om energie aan te spandeer? Want oor die algemeen is dit moeilik. As jy so probeer werk, sal jy verstaan dat sommige beplanning nou geraak sal word, jy sal meer tyd aan ontbindtake moet bestee. Want as jy dit doen man..., dan sal jy nie vinnig tot verhaal kan kom nie en daarvolgens in die moeilikheid beland. Jy sal nie meer oefening hê nie.
En dit sal duur wees. Dit sal nie moontlik wees om onmiddellik van môre af te werk deur deurlopende integrasie te gebruik nie. Dit sal julle almal baie lank neem om daaraan gewoond te raak, dit sal julle baie lank neem om gewoond te raak aan ontbindende take, dit sal baie lank neem om gewoond te raak om die hersieningspraktyk oor te doen, as jy een het . Want ons doel is dat dit vandag smelt. En as jy binne drie dae 'n hersiening doen, dan het jy probleme en Deurlopende integrasie werk nie vir jou nie.
Maar het ons nou enige relevante bewyse wat vir ons sê dat belegging in hierdie praktyk sin maak?
Die eerste ding wat by my opgekom het, was State of DevOps. Dit is 'n studie wat die ouens al 7 jaar lank doen. Nou doen hulle dit as 'n onafhanklike organisasie, maar onder Google.
En hul 2018-studie het 'n korrelasie getoon tussen maatskappye wat probeer om kortstondige takke te gebruik wat vinnig integreer, gereeld integreer en beter IT-prestasie-aanwysers het.
Wat is hierdie aanwysers? Dit is 4 maatstawwe wat hulle van alle maatskappye in hul vraelyste neem: ontplooiingsfrekwensie, deurlooptyd vir veranderinge, tyd om diens te herstel, verandering van mislukkingskoers.
En eerstens is daar hierdie korrelasie, ons weet dat maatskappye wat gereeld meet, baie beter statistieke het. En hulle het 'n verdeling van maatskappye in verskeie kategorieë: dit is stadige maatskappye wat iets stadig produseer, mediumpresteerder, hoëpresteerder en elite. Die elite is Netflix, Amazon, wat super vinnig is, alles vinnig, pragtig en doeltreffend doen.
Die tweede storie, wat net 'n maand gelede gebeur het. Tegnologie Radar het 'n wonderlike artikel oor Gitflow. Gitflow verskil van alle ander in die sin dat sy takke langlewend is. Daar is vrylatingtakke wat lank leef, en kenmerktakke wat ook lank leef. Hierdie praktyk by Tegnologie Radar het na HOLD geskuif. Hoekom? Omdat mense die pyn van integrasie in die gesig staar.
As jou tak baie lank leef, sit dit vas, raak vrot, en ons begin meer tyd spandeer om een of ander verandering daaraan te probeer maak.
En onlangs het die skrywer van Gitflow gesê dat as jou doel deurlopende integrasie is, as jou doel is dat jy so gereeld as moontlik wil rol, dan is Gitflow 'n slegte idee. Hy het apart by die artikel bygevoeg dat as jy 'n backend het waar jy daarna kan streef, dan is Gitflow vir jou oorbodig, want Gitflow sal jou stadiger maak, Gitflow sal vir jou probleme skep met integrasie.
Dit beteken nie dat Gitflow sleg is en nie gebruik moet word nie. Dis vir ander geleenthede. Byvoorbeeld, wanneer jy verskeie weergawes van 'n diens of toepassing moet ondersteun, dit wil sê waar jy ondersteuning nodig het vir 'n lang tydperk.
Maar as jy met mense praat wat sulke dienste ondersteun, sal jy baie pyn hoor oor die feit dat hierdie weergawe 3.2 was, wat 4 maande gelede was, maar hierdie oplossing is nie daarin ingesluit nie en nou, om dit te maak, jy moet 'n klomp veranderinge maak. En nou sit hulle weer vas, en nou het hulle vir 'n week rondgevroetel om 'n nuwe funksie te probeer implementeer.
Soos Alexander Kovalev korrek in die klets opgemerk het, is korrelasie nie dieselfde as oorsaaklikheid nie. Dit is waar. Dit wil sê, daar is geen direkte verband dat as u deurlopende integrasie het, al die statistieke wonderlik sal wees nie. Maar daar is 'n positiewe korrelasie dat as een een is, dan is die ander heel waarskynlik ook. Nie 'n feit nie, maar heel waarskynlik. Dit is net 'n korrelasie.
Dit blyk dat ons reeds iets doen, dit blyk dat ons reeds saamsmelt, maar hoe kan ons verstaan dat ons nog steeds Deurlopende Integrasie het, dat ons nogal dikwels saamsmelt?
Jez Humble is die skrywer van Handbook, Accelerate, die Continuous Delivery-webwerf en die boek Continuous Delivery. Hy bied hierdie toets aan:
- Die ingenieur se kode kom elke dag na die meester.
- Vir elke commit voer jy eenheidstoetse uit.
- Die gebou in die meester het geval, dit is in ongeveer 10 minute reggemaak.
Hy stel voor om 'n toets soos hierdie te gebruik om seker te maak jy het genoeg oefening.
Ek vind laasgenoemde 'n bietjie kontroversieel. Dit wil sê, as jy dit in 10 minute kan regmaak, dan het jy Continuous Integration, dit klink 'n bietjie vreemd, na my mening, maar dit maak sin. Hoekom? Want as jy gereeld vries, beteken dit dat jou veranderinge klein is. As 'n klein verandering beteken dat jou meesterbou gebreek is, dan kan jy vinnig 'n voorbeeld vind, want die verandering is klein. Hier het jy 'n klein samesmelting gehad, 20-30 reëls daarin het verander. En gevolglik kan jy vinnig verstaan wat die rede was, want die veranderinge is klein, jy het 'n baie klein area om na die probleem te soek.
En selfs as ons prod uitmekaar val na die vrystelling, as ons dan die praktyk van Deurlopende Integrasie het, is dit vir ons baie makliker om op te tree, want die veranderinge is klein. Ja, dit sal beplanning beïnvloed. Dit sal seermaak. En, waarskynlik, die moeilikste ding in hierdie praktyk is om gewoond te raak aan die afbreek van take, dit wil sê hoe om dit te doen sodat jy iets kan neem en dit binne 'n paar uur kan doen en terselfdertyd 'n resensie kan slaag, as jy het een. Hersiening is 'n aparte pyn.
Eenheidtoetse is net 'n assistent wat jou help om te verstaan of jou integrasie suksesvol was en of niks gebreek is nie. Dit is myns insiens ook nie heeltemal verpligtend nie, want dit is nie die punt van oefening nie.
Hierdie is 'n kort inleiding tot Deurlopende Integrasie. Dit is al wat daar aan hierdie praktyk is. Ek is gereed vir vrae.
Ek sal net weer kortliks opsom:
- Deurlopende integrasie is nie Jenkins nie, dit is nie Gitlab nie.
- Dit is nie 'n instrument nie, dit is 'n praktyk dat ons ons kode so dikwels as moontlik in die meester saamvoeg.
- Ons doen dit om die enorme pyn te vermy wat met samesmeltings in die toekoms ontstaan, dit wil sê, ons ervaar nou 'n bietjie pyn om nie meer in die toekoms te ervaar nie. Dit is die hele punt.
- Aan die kant is daar kommunikasie deur middel van kode, maar ek sien dit baie selde, maar dit is ook waarvoor dit ontwerp is.
vrae
Wat om te doen met nie-ontbinde take?
Ontbind. Wat is die probleem? Kan jy 'n voorbeeld gee dat daar 'n taak is en dit is nie ontbind nie?
Daar is take wat nie van die woord “heeltemal” ontbind kan word nie, byvoorbeeld dié wat baie diep kundigheid verg en wat eintlik oor die loop van ’n maand opgelos kan word om een of ander verteerbare resultaat te behaal.
As ek jou reg verstaan, is daar 'n groot en komplekse taak, waarvan die resultaat eers oor 'n maand sigbaar sal wees?
Ja, dis reg. Ja, dit sal moontlik wees om die resultaat nie vroeër as oor 'n maand te evalueer nie.
Goed. Oor die algemeen is dit nie 'n probleem nie. Hoekom? Want in hierdie geval, wanneer ons van takkies praat, praat ons nie van 'n takkie met 'n kenmerk nie. Kenmerke kan groot en kompleks wees. Hulle kan 'n groot aantal komponente beïnvloed. En miskien kan ons dit nie heeltemal in een tak doen nie. Dit is goed. Ons moet net hierdie storie afbreek. As 'n kenmerk nie heeltemal gereed is nie, beteken dit nie dat sommige stukke van sy kode nie saamgevoeg kan word nie. Jy het byvoorbeeld migrasie bygevoeg en daar is 'n paar stadiums in die funksie. Kom ons sê jy het 'n verhoog - maak 'n migrasie, voeg 'n nuwe metode by. En jy kan hierdie dinge reeds elke dag meet.
Goed. Wat is die punt dan?
Wat is die punt daarvan om elke dag klein goedjies dood te maak?
Ja.
As hulle iets breek, sien jy dit dadelik. Jy het 'n klein stukkie wat iets gebreek het, dit is makliker vir jou om dit reg te maak. Die punt is dat die samesmelting van 'n klein stukkie nou baie makliker is as om iets groots in 'n paar weke saam te voeg. En die derde punt is dat ander ingenieurs met die huidige weergawe van die kode sal werk. Hulle sal sien dat sommige migrasies hier bygevoeg is, en dan het een of ander metode verskyn wat hulle dalk ook wil gebruik. Almal sal sien wat in jou kode gebeur. Dit is vir hierdie drie dinge wat oefening gedoen word.
Dankie, die uitgawe is gesluit!
(Oleg Soroka) Mag ek byvoeg? Jy het alles reg gesê, ek wil net een frase byvoeg.
So.
Met deurlopende integrasie word die kode in 'n gemeenskaplike tak saamgevoeg, nie wanneer die kenmerk heeltemal gereed is nie, maar wanneer die bou ophou breek. En jy kan jou veilig verbind om soveel keer per dag te bemeester as wat jy wil. Die tweede aspek is dat as jy om een of ander rede nie die maandelikse taak vir minstens drie dae in take kan opbreek nie, ek swyg so drie uur, dan het jy 'n groot probleem. En die feit dat jy nie deurlopende integrasie het nie, is die minste van hierdie probleme. Dit beteken dat jy probleme het met argitektuur en geen ingenieurspraktyke nie. Want al is dit navorsing, dan moet dit in elk geval in die vorm van hipoteses of 'n siklus geformuleer word.
Ons het gepraat oor 4 maatstawwe wat suksesvolle maatskappye van agterstalliges onderskei. Ons moet nog lewe om hierdie 4 maatstawwe te sien. As jou gemiddelde taak 'n maand neem om te voltooi, dan sal ek eers op hierdie maatstaf fokus. Ek sal dit eers na 3 dae verlaag. En daarna het ek aan Continuous begin dink.
Het ek jou reg verstaan dat jy dink dat daar oor die algemeen geen sin is om in ingenieurspraktyke te belê as enige taak 'n maand neem om te voltooi nie?
Jy het deurlopende integrasie. En daar is so 'n onderwerp dat jy binne 10 minute óf 'n regstelling kan regmaak óf dit kan terugrol. Stel jou voor jy het dit uitgerol. Boonop het u selfs deurlopende ontplooiing, u het dit uitgerol om aan te dryf en toe eers opgemerk dat iets verkeerd geloop het. En jy moet dit terugrol, maar jy het reeds jou databasis gemigreer. Jy het reeds die databasisskema van die volgende weergawe, boonop het jy ook 'n soort rugsteun gehad, en die data is ook daar geskryf.
En watter alternatief het jy? As jy die kode terugrol, kan dit nie meer met hierdie opgedateerde databasis werk nie.
Die basis beweeg net vorentoe, ja.
Mense wat swak ingenieurspraktyke het, het heel waarskynlik ook nie die dik boek oor ... gelees nie. Wat om te doen met die rugsteun? As jy herstel vanaf 'n rugsteun, beteken dit dat jy die data verloor wat jy gedurende daardie oomblik opgehoop het. Ons het byvoorbeeld drie uur lank gewerk met die nuwe weergawe van die databasis, gebruikers het daar geregistreer. Jy weier die ou rugsteun omdat die skema nie met die nuwe weergawe werk nie, so jy het hierdie gebruikers verloor. En hulle is ontevrede, hulle sweer.
Om die volle reeks praktyke te bemeester wat deurlopende integrasie en deurlopende aflewering ondersteun, is dit nie genoeg om net te leer hoe om te skryf nie.... Eerstens kan daar baie van hulle wees, dit sal onprakties wees. Boonop is daar 'n klomp ander praktyke soos Scientific. Daar is so 'n praktyk, GitHub het dit op 'n tyd gewild gemaak. Dit is wanneer jy beide ou kode en nuwe kode op dieselfde tyd loop. Dit is wanneer jy 'n onvoltooide kenmerk maak, maar dit kan 'n mate van waarde terugstuur: óf as 'n funksie óf as 'n Rest API. Jy voer beide die nuwe kode en die ou kode uit, en vergelyk die verskil tussen hulle. En as daar 'n verskil is, teken jy hierdie gebeurtenis aan. Op hierdie manier weet jy dat jy 'n nuwe kenmerk gereed het om bo-op die ou een uit te rol as jy vir 'n sekere tyd nie 'n verskil tussen die twee gehad het nie.
Daar is honderde sulke praktyke. Ek sou voorstel om met transbasisontwikkeling te begin. Sy is nie 100% op Deurlopende Integrasie nie, maar die praktyke is dieselfde, die een kan nie goed leef sonder die ander nie.
Het jy transbasis-ontwikkeling as 'n voorbeeld gegee waar jy praktyke kan sien of stel jy voor dat mense transbasis-ontwrigting begin gebruik?
Kyk gerus, want hulle sal dit nie kan gebruik nie. Om dit te gebruik, moet jy baie lees. En wanneer 'n persoon vra: "Wat om te doen met 'n kenmerk wat 'n maand neem, beteken dit dat hy nie oor transbasisontwikkeling gelees het nie." Ek sal dit nog nie aanbeveel nie. Ek sal aanbeveel om net te fokus op die onderwerp van hoe om groot take argitektonies korrek in kleineres af te breek. Dit is die essensie van ontbinding.
Ontbinding is een van die argitek se gereedskap. Ons doen eers analise, dan ontbinding, dan sintese, dan integrasie. En dit is hoe alles vir ons uitwerk. En ons moet steeds groei tot deurlopende integrasie deur ontbinding. Vrae ontstaan in die eerste stadium, en ons praat reeds van die vierde stadium, dit wil sê hoe meer gereeld ons integrasie doen, hoe beter. Dit is nog te vroeg om dit te doen; dit sal lekker wees om eers jou monoliet af te sny.
Jy moet 'n aantal pyle en vierkante op een of ander diagram teken. Jy kan nie sê dat ek nou die argitektoniese diagram van 'n nuwe toepassing sal wys en een vierkant sal wys, waarin daar 'n groen knoppie vir die toepassing is nie. In elk geval sal daar meer blokkies en pyle wees. Elke diagram wat ek gesien het, het meer as een gehad. En ontbinding, selfs op die vlak van grafiese voorstelling, vind reeds plaas. Daarom kan die vierkante onafhanklik gemaak word. Indien nie, dan het ek groot vrae vir die argitek.
Daar is 'n vraag uit die klets: "As 'n hersiening verpligtend is en lank neem, miskien 'n dag of meer?"
Jy het probleme met oefening. Die hersiening moet nie 'n dag of langer duur nie. Dit is dieselfde storie as die vorige vraag, net 'n bietjie sagter. As 'n hersiening vir 'n dag duur, sal hierdie resensie waarskynlik 'n baie groot verandering ondergaan. Dit beteken dat dit kleiner gemaak moet word. In transbasisontwikkeling, wat Oleg aanbeveel het, is daar 'n storie genaamd deurlopende hersiening. Haar idee is dat ons doelbewus so 'n klein trekversoek doen, want ons streef daarna om voortdurend en bietjie op 'n slag saam te smelt. En so verander die trekversoek een abstraksie of 10 reëls. Danksy hierdie resensie neem dit ons 'n paar minute.
As die hersiening 'n dag of meer neem, is iets fout. Eerstens kan u probleme met die argitektuur hê. Of dit is 'n groot stuk kode, byvoorbeeld 1 000 reëls. Of jou argitektuur is so kompleks dat 'n persoon dit nie kan verstaan nie. Dit is 'n effens sywaartse probleem, maar dit sal ook opgelos moet word. Miskien is dit glad nie nodig vir 'n resensie nie. Ons moet ook hieroor dink. Resensie is die ding wat jou vertraag. Dit het sy voordele oor die algemeen, maar jy moet verstaan hoekom jy dit doen. Is dit 'n manier vir jou om vinnig inligting oor te dra, is dit 'n manier vir jou om 'n paar standaarde intern te stel of wat? Hoekom het jy dit nodig? Omdat die hersiening óf baie vinnig gedoen moet word óf heeltemal gekanselleer moet word. Dit is soos transbasis-ontwikkeling – die storie is baie mooi, maar net vir volwasse ouens.
Wat die 4 maatstawwe betref, sal ek steeds aanbeveel om dit te verwyder om te verstaan waartoe dit lei. Kyk na die getalle, kyk na die prentjie, hoe sleg alles is.
(Dmitry) Ek is gereed om hieroor met jou in gesprek te tree. Getalle en statistieke is almal wonderlik, praktyke is wonderlik. Maar jy moet verstaan of die besigheid dit nodig het. Daar is besighede wat nie daardie soort spoed van verandering nodig het nie. Ek ken maatskappye waar veranderinge nie elke 15 minute gemaak kan word nie. En nie omdat hulle so sleg is nie. Dit is so 'n lewensiklus. En om die takke te laat kenmerk, die wisselfunksie, het jy diep kennis nodig.
Dis ingewikkeld. As jy die storie oor die wisselfunksie in meer besonderhede wil lees, beveel ek dit sterk aan . En daar is 'n wonderlike artikel deur Martin Fowler oor wisselfunksies: watter tipes daar is, lewensiklusse, ens. Die wisselfunksie is ingewikkeld.
En jy het steeds nie die vraag beantwoord nie: "Is Jenkins nodig of nie?"
Jenkins is in elk geval nie nodig nie. Maar ernstig, die gereedskap: Jenkins, Gitlab sal jou gerief bring. Jy sal sien dat die samestelling aanmekaargesit is of nie saamgestel is nie. Hulle kan jou help, maar hulle sal jou nie oefening gee nie. Hulle kan net vir jou 'n sirkel gee - Ok, nie Ok nie. En dan, as jy ook toetse skryf, want as daar nie toetse is nie, dan is dit amper sinloos. Daarom is dit nodig omdat dit geriefliker is, maar oor die algemeen kan jy daarsonder leef, jy sal nie veel verloor nie.
Dit wil sê, as jy praktyke het, beteken dit dat jy dit nie nodig het nie?
Dit is reg. Ek beveel die Jez Humble-toets aan. Daar het ek 'n ambivalente houding teenoor die laaste punt. Maar oor die algemeen, as jy drie dinge het, smelt jy voortdurend saam, jy voer toetse oor commits in die meester uit, jy maak vinnig die bou in die meester reg, dan het jy miskien niks anders nodig nie.
Terwyl ons wag vir vrae van deelnemers, het ek 'n vraag. Ons het net oor die produkkode gepraat. Het jy dit vir infrastruktuurkode gebruik? Is dit dieselfde kode, het dit dieselfde beginsels en dieselfde lewensiklus, of is daar verskillende lewensiklusse en beginsels? Gewoonlik, wanneer almal praat oor deurlopende integrasie en ontwikkeling, vergeet almal dat daar ook infrastruktuurkode is. En die afgelope tyd is daar meer en meer daarvan. En moet al hierdie reëls daarheen gebring word?
Nie eers dat dit moet wees nie, dit sal wonderlik wees, want dit sal die lewe op dieselfde manier makliker maak. Sodra ons met kode werk, nie met bash-skrifte nie, maar ons het normale kode.
Stop, stop, 'n bash script is ook kode. Moenie aan my ou liefde raak nie.
Goed, ek sal nie op jou herinneringe vertrap nie. Ek het 'n persoonlike afkeer vir bash. Dit breek heeltyd lelik en skrikwekkend. En dit breek dikwels onvoorspelbaar, en daarom hou ek nie daarvan nie. Maar goed, kom ons sê jy het bash-kode. Miskien verstaan ek regtig nie en is daar normale toetsraamwerke daar buite. Ek is net nie in die wete nie. En ons kry dieselfde voordele.
Sodra ons met infrastruktuur as kode werk, kry ons almal dieselfde probleme as ontwikkelaars. 'n Paar maande gelede het ek 'n situasie teëgekom waar 'n kollega vir my 'n trekversoek gestuur het vir 1 000 reëls in bash. En jy kuier vir 4 uur by die resensie. Dieselfde probleme ontstaan. Dit is steeds kode. En dit is steeds 'n samewerking. Ons sit vas met die trekversoek en ons sit vas met die feit dat ons byvoorbeeld dieselfde samesmeltingskonflikte in dieselfde bash oplos.
Ek kyk nou baie aktief na hierdie hele ding op die mooiste infra-programmering. Ek het Pulumi nou in die infrastruktuur ingebring. Dit is programmering in sy suiwerste vorm. Daar is dit selfs lekkerder, want ek het al die vermoëns van 'n programmeertaal, d.w.s. ek het pragtige toggle uit die bloute gemaak met dieselfde ifs en alles is reg. Dit wil sê, my verandering is reeds in die meester. Almal kan hom reeds sien. Ander ingenieurs weet daarvan. Dit het reeds iets daar beïnvloed. Dit was egter nie vir alle infrastruktuur geaktiveer nie. Dit het byvoorbeeld vir my toetsbanke aangeskakel. Daarom, om jou vraag weer te beantwoord, is dit nodig. Dit maak die lewe vir ons, as ingenieurs wat met kode werk, op dieselfde manier makliker.
As iemand anders vrae het?
Ek het 'n vraag. Ek wil die gesprek met Oleg voortsit. Oor die algemeen dink ek dat jy reg is, dat as 'n taak 'n maand neem om te voltooi, dan het jy 'n probleem met argitektuur, jy het 'n probleem met ontleding, ontbinding, beplanning, ens. Maar ek het 'n gevoel dat as jy begin probeer leef volgens Continuous Integration, dan sal jy begin om die pyn reg te stel met beplanning, want jy sal nêrens anders daarvan wegkom nie.
(Oleg) Ja, dis reg. Hierdie praktyk is in poging vergelykbaar met enige ander ernstige kultuurveranderende praktyk. Die moeilikste ding om te oorkom is gewoontes, veral slegte gewoontes. En as om hierdie praktyk te implementeer, 'n ernstige verandering in die gewoontes van diegene rondom jou vereis word: ontwikkelaars, bestuur, produksiebestuurder, dan wag verrassings op jou.
Watter verrassings kan daar wees? Kom ons sê jy besluit dat jy meer gereeld sal integreer. En jy het 'n paar ander dinge wat verband hou met integrasie, byvoorbeeld artefakte. En in jou maatskappy, byvoorbeeld, is daar 'n beleid dat elke artefak op een of ander manier in 'n soort artefakbergingstelsel verantwoord moet word. En dit neem 'n rukkie. 'n Persoon moet die blokkie merk dat hy, as 'n vrystellingbestuurder, hierdie artefak getoets het om te verseker dat dit gereed is vir vrystelling in produksie. As dit 5-10-15 minute neem, maar jy doen die uitleg een keer per week, dan is dit 'n klein belasting om 'n halfuur een keer per week te spandeer.
As jy deurlopende integrasie 10 keer per dag doen, moet 10 keer met 30 minute vermenigvuldig word. En dit oorskry die hoeveelheid werktyd van hierdie vrystellingbestuurder. Hy word net moeg om dit te doen. Daar is vaste koste vir sommige praktyke. Dis al.
En jy moet óf hierdie reël kanselleer sodat jy nie meer sulke vullis doen nie, d.w.s. jy ken nie met die hand 'n graad toe om met iets ooreen te stem nie. Jy maak heeltemal staat op een of ander outomatiese stel gereedheidstoetse.
En as jy bewyse van iemand nodig het, sodat die baas dit teken, en jy nie in produksie kom sonder dat Vasya sê dat hy dit toelaat nie, ens. - al hierdie nonsens kom in die pad van die praktisyn. Want as daar 'n paar aktiwiteite is wat verband hou met 'n belasting, dan verhoog alles 100 keer. Daarom sal die skof dikwels nie deur almal met vreugde begroet word nie. Omdat mense se gewoontes moeilik is om te verander.
Wanneer 'n persoon sy gewone werk doen, doen hy dit amper sonder om te dink. Haar kognitiewe las is nul. Hy speel net daarmee, hy het reeds 'n kontrolelys in sy kop, hy het dit al 'n duisend keer gedoen. En sodra jy vir hom kom sê: "Kom ons kanselleer hierdie oefening en stel 'n nuwe een bekend vanaf Maandag," word dit vir hom 'n kragtige kognitiewe las. En dit kom op een slag na almal toe.
Daarom is die eenvoudigste ding, hoewel nie almal hierdie luukse kan bekostig nie, maar dit is wat ek altyd doen, dit is die volgende. As 'n nuwe projek begin, dan word gewoonlik alle ongetoetste praktyke onmiddellik in hierdie projek ingeprop. Terwyl die projek jonk is, waag ons niks regtig nie. Daar is nog geen Prod nie, daar is niks om te vernietig nie. Daarom kan dit as opleiding gebruik word. Hierdie benadering werk. Maar nie alle maatskappye het die geleentheid om sulke projekte gereeld te begin nie. Alhoewel dit ook 'n bietjie vreemd is, want nou is daar 'n volledige digitale transformasie, moet almal eksperimente loods om tred te hou met mededingers.
Hier kom jy tot die gevolgtrekking dat jy eers 'n begrip moet hê van wat jy moet doen. Die wêreld is nie ideaal nie, en prod is ook nie ideaal nie.
Ja, hierdie dinge is onderling verbind.
Besighede verstaan ook nie altyd dat hulle hierdie kant toe moet gaan nie.
Daar is 'n situasie waarin geen veranderings hoegenaamd moontlik is nie. Dit is ’n situasie waar daar meer druk op die span is. Die span is reeds redelik uitgebrand. Sy het geen vrye tyd vir enige eksperimente nie. Hulle werk van oggend tot aand aan kenmerke. En die bestuur het al hoe minder funksies. Meer en meer word vereis. In so 'n situasie is geen veranderinge hoegenaamd moontlik nie. Die span kan net gesê word dat ons môre dieselfde sal doen as gister, ons moet net 'n bietjie meer funksies maak. In hierdie sin is geen oorgange na enige praktyke moontlik nie. Dit is 'n klassieke situasie wanneer daar nie tyd is om die byl skerp te maak nie, bome moet afgekap word, so hulle sny dit met 'n dowwe byl. Hier is geen eenvoudige wenke nie.
(Dmitry) Ek sal 'n verduideliking uit die klets voorlees: "Maar ons het baie toetsdekking op verskillende vlakke nodig. Hoeveel tyd word vir toetse toegeken? Dit is 'n bietjie duur en neem baie tyd in beslag.”
(Oleg) Dit is 'n klassieke wanopvatting. Daar moet genoeg toetse wees vir jou om selfversekerd te wees. Deurlopende integrasie is nie 'n ding waar 100% van die toetse eers gedoen word en eers dan begin jy hierdie praktyk toepas nie. Deurlopende integrasie verminder jou kognitiewe las as gevolg van die feit dat elkeen van die veranderinge wat jy met jou oë sien so duidelik is dat jy verstaan of dit iets sal breek of nie, selfs sonder toetse. Jy kan dit vinnig in jou kop toets, want die veranderinge is klein. Selfs as jy net handtoetsers het, is dit ook makliker vir hulle. Jy het uitgerol en gesê: "Kyk, is iets stukkend?" Hulle het nagegaan en gesê: "Nee, niks is gebreek nie." Want die toetser weet waar om te kyk. Jy het een commit wat verband hou met een stuk kode. En dit word uitgebuit deur spesifieke gedrag.
Hier het jy natuurlik verfraai.
(Dmitry) Ek stem nie hier saam nie. Daar is 'n praktyk - toetsgedrewe ontwikkeling wat jou hiervan sal red.
(Oleg) Wel, ek het nog nie by daardie punt gekom nie. Die eerste illusie is dat jy 100% van die toetse moet skryf of jy hoef glad nie Deurlopende integrasie te doen nie. Dis nie waar nie. Dit is twee parallelle praktyke. En hulle is nie direk afhanklik nie. Jou toetsdekking moet optimaal wees. Optimaal - dit beteken dat jy self vol vertroue is dat die kwaliteit van die meester waarin jou meester gebly het na die commit jou toelaat om met selfvertroue op 'n dronk Vrydagaand die "Deploy"-knoppie te druk. Hoe bereik jy dit? Deur hersiening, deur dekking, deur goeie monitering.
Goeie monitering is nie te onderskei van toetse nie. As jy een keer toetse op pre-prod uitvoer, dan gaan hulle al jou gebruikersskrifte een keer na en dit is dit. En as jy hulle in 'n eindelose lus laat loop, dan is dit jou ontplooide moniteringstelsel, wat alles eindeloos toets - of dit neergestort het of nie. In hierdie geval is die enigste verskil of dit een of twee keer gedoen word. 'n Baie goeie stel toetse ... loop eindeloos, dit is monitering. En behoorlike monitering moet so wees.
En daarom, hoe presies jy hierdie toestand sal bereik wanneer jy Vrydagaand gereed maak en huis toe gaan, is 'n ander vraag. Miskien is jy maar net 'n dapper skelm.
Kom ons gaan 'n bietjie terug na Deurlopende integrasie. Ons het weggehardloop in 'n effens ander komplekse praktyk.
En die tweede illusie is dat MVP, sê hulle, vinnig gedoen moet word, so toetse is glad nie daar nodig nie. Nie seker op die manier nie. Die feit is dat wanneer jy 'n gebruikersstorie in 'n MVP skryf, jy dit óf op die bal kan ontwikkel, dit wil sê, jy het gehoor dat daar 'n soort gebruikersstorie was en dadelik gehardloop het om dit te kodeer, óf jy kan met TDD werk. En volgens TDD, soos die praktyk toon, neem dit nie langer nie, dit wil sê toetse is 'n newe-effek. Die praktyk van TDD gaan nie oor toetsing nie. Ten spyte van wat genoem word toetsgedrewe ontwikkeling, gaan dit glad nie oor toetse nie. Dit is ook eerder 'n argitektoniese benadering. Dit is 'n benadering om presies te skryf wat nodig is en nie te skryf wat nie nodig is nie. Dit is 'n praktyk om te fokus op die volgende iterasie van jou denke in terme van die skep van 'n toepassingsargitektuur.
Daarom is dit nie so maklik om van hierdie illusies ontslae te raak nie. MVP en toetse weerspreek mekaar nie. Selfs, eerder, inteendeel, as jy MVP met TDD-oefening doen, dan sal jy dit beter en vinniger doen as wanneer jy dit enigsins sonder oefening doen, maar op 'n bal.
Dit is 'n baie nie-vanselfsprekende en komplekse idee. As jy hoor dat ek nou meer toetse sal skryf en terselfdertyd iets vinniger sal doen, klink dit absoluut onvoldoende.
(Dmitry) Baie mense hier, wanneer hulle MVP bel, is mense te lui om iets normaals te skryf. En dit is steeds verskillende dinge. Dit is nie nodig om MVP in 'n slegte ding te verander wat nie werk nie.
Ja, ja, jy is reg.
En toe skielik MVP in prod.
Vir ewig.
En TDD klink baie ongewoon as jy hoor jy skryf toetse en lyk asof jy meer werk doen. Dit klink baie vreemd, maar in werklikheid blyk dit vinniger en mooier op hierdie manier. Wanneer jy ’n toets skryf, dink jy reeds baie in jou kop oor watter kode genoem gaan word en hoe, asook watter gedrag ons daarvan verwag. Jy sê nie net ek het een of ander funksie geskryf en dit doen iets nie. Jy het eers gedink sy het sulke en sulke toestande, daar sou op so en so 'n manier na haar toe geroep word. Jy dek dit met toetse en hieruit verstaan jy hoe jou koppelvlakke binne jou kode sal lyk. Dit het 'n groot impak op argitektuur. Jou kode word outomaties meer modulêr, want jy probeer eers verstaan hoe jy dit gaan toets, en skryf dit dan eers.
Wat met my gebeur het met TDD was dat ek op 'n stadium 'n Ruby-mentor aangestel het toe ek nog 'n Ruby-programmeerder was. En hy sê: "Kom ons doen dit volgens TDD." Ek het gedink: “Verdomp, nou moet ek iets ekstra skryf.” En ons het ooreengekom dat ek binne twee weke al die werkskode in Python sal skryf deur TDD te gebruik. Na twee weke het ek besef dat ek nie wil teruggaan nie. Na twee weke se probeer om dit oral toe te pas, besef jy hoeveel makliker dit vir jou geword het om selfs net te dink. Maar dit is nie voor die hand liggend nie, so ek beveel aan almal dat as jy die gevoel het dat TDD moeilik, tydrowend en onnodig is, probeer om dit vir net twee weke te hou. Twee was genoeg vir my.
(Dmitry) Ons kan hierdie idee uitbrei vanuit die oogpunt van infrastruktuurbedryf. Voordat ons iets nuuts bekendstel, doen ons monitering en begin dan. In hierdie geval word monitering normale toetsing vir ons. En daar is ontwikkeling deur monitering. Maar byna almal sê dat dit lank is, ek is lui, ek het 'n tydelike konsep gemaak. As ons normale monitering gedoen het, verstaan ons die toestand van die CI-stelsel. En die CI-stelsel het baie monitering. Ons verstaan die toestand van die stelsel, ons verstaan wat daarin is. En tydens ontwikkeling maak ons net die stelsel sodat dit die verlangde toestand bereik.
Hierdie praktyke is al lank bekend. Ons het dit so 4 jaar gelede bespreek. Maar in 4 jaar het feitlik niks verander nie.
Maar op hierdie noot stel ek voor om die amptelike bespreking te beëindig.
Video (ingevoeg as 'n media-element, maar om een of ander rede werk dit nie):
Bron: will.com