Haai Habr! Ek het vroeër gekla oor die lewe in die Infrastruktuur as kodeparadigma en het niks aangebied om die huidige situasie op te los nie. Vandag het ek teruggekeer om jou te vertel watter benaderings en praktyke jou sal help om uit die afgrond van wanhoop te ontsnap en die situasie in die regte rigting te stuur.
In 'n vorige artikel Ek het my indrukke van hierdie area gedeel, probeer besin oor die huidige situasie in hierdie area, en selfs voorgestel dat standaardpraktyke wat aan alle ontwikkelaars bekend is, kan help. Dit mag lyk asof daar baie klagtes oor die lewe was, maar daar was geen voorstelle vir 'n uitweg uit die huidige situasie nie.
Wie ons is, waar ons is en watter probleme ons het
Ons is nou in die Sre Onboarding Team, wat bestaan uit ses programmeerders en drie infrastruktuuringenieurs. Ons probeer almal om Infrastruktuur as kode (IaC) te skryf. Ons doen dit omdat ons in beginsel weet hoe om kode te skryf en in die anamnese is ons ontwikkelaars van die "bo-gemiddelde" vlak.
- Ons het 'n stel voordele: 'n sekere agtergrond, kennis van praktyke, die vermoë om kode te skryf, 'n begeerte om nuwe dinge te leer.
- En daar is 'n afsakkende deel, wat ook 'n minus is: 'n gebrek aan kennis oor die toerusting van die infrastruktuur.
Die stapel tegnologieë wat ons in ons IaC gebruik.
- Terraform vir die skep van hulpbronne.
- Verpakker vir die bou van beelde. Dit is Windows, CentOS 7 beelde.
- Jsonnet om kragtige bouwerk in drone.io te doen, asook om pakker json en ons terraform-modules te genereer.
- Blou.
- Dit is moontlik wanneer beelde gekook word.
- Python vir hulpdienste, sowel as voorsiening van skrifte.
- En dit alles in VSCode met inproppe wat tussen spanlede gedeel word.
uitset van my Ek was so: Ek het probeer om (in die eerste plek in myself) optimisme te inspireer, ek wou sê dat ons die benaderings en praktyke wat aan ons bekend is, sal probeer om die probleme en probleme wat op hierdie gebied bestaan, te hanteer.
Ons sukkel tans met die volgende IaC-kwessies:
- Onvolmaaktheid van gereedskap, middele vir kode-ontwikkeling.
- Stadige ontplooiing. Infrastruktuur is deel van die werklike wêreld, en dit kan stadig wees.
- Gebrek aan benaderings en praktyke.
- Ons is nuut en weet nie veel nie.
Ekstreme programmering (XP) tot die redding
Alle ontwikkelaars is vertroud met Extreme Programming (XP) en die praktyke daaragter. Baie van ons het aan hierdie benadering gewerk, en dit was suksesvol. So hoekom nie voordeel trek uit die beginsels en praktyke wat daar neergelê is om infrastruktuurprobleme te oorkom nie? Ons het besluit om hierdie benadering te volg en te kyk wat gebeur.
Kontroleer die toepaslikheid van die XP-benadering op jou veldHier is 'n beskrywing van die omgewing waarvoor XP goed geskik is, en hoe dit met ons verband hou:
1. Dinamies veranderende sagteware vereistes. Ons het geweet wat die einddoel was. Maar die besonderhede kan verskil. Ons besluit self waarheen ons moet taxi, so die vereistes verander periodiek (meestal self). As ons die SRE-span neem, wat self outomatisering doen, en self die vereistes en omvang van werk beperk, dan pas hierdie item goed.
2. Risiko's wat veroorsaak word deur vaste tydprojekte wat nuwe tegnologie gebruik. Ons kan risiko's hê wanneer ons sekere dinge wat aan ons onbekend is, gebruik. En dit is 100% ons geval. Ons hele projek is die gebruik van tegnologie waarmee ons nie ten volle vertroud was nie. Oor die algemeen is dit 'n konstante probleem, want. In infrastruktuur is daar heeltyd baie nuwe tegnologieë wat opduik.
3,4. Klein, saamgeleë uitgebreide ontwikkelingspan. Die tegnologie wat jy gebruik maak voorsiening vir outomatiese eenheid- en funksionele toetse. Hierdie twee punte pas ons nie heeltemal nie. Eerstens is ons nie 'n saamgelokaliseerde span nie, en tweedens is daar nege van ons, wat as 'n groot span beskou kan word. Alhoewel, volgens 'n aantal definisies van 'n "groot" span, is baie 14+ mense.
Kom ons kyk na 'n paar praktyke van XP en hoe dit die spoed en kwaliteit van terugvoer beïnvloed.
Terugvoerlus-beginsel in XP
Na my begrip is terugvoer die antwoord op die vraag, doen ek die regte ding, gaan ons soontoe? In XP is daar 'n goddelike skema hiervoor: 'n terugvoerlus in tyd. Die interessante ding is dat hoe laer ons is, hoe vinniger kan ons die bedryfstelsel kry om die nodige vrae te beantwoord.
Dit is nogal 'n interessante onderwerp vir bespreking dat ons in die IT-bedryf vinnig 'n bedryfstelsel kan kry. Stel jou voor hoe pynlik dit is om 'n projek vir ses maande te doen en dan eers uit te vind dat 'n fout aan die begin gemaak is. Dit gebeur in ontwerp, en in enige konstruksie van komplekse stelsels.
In ons geval help IaC ons met terugvoer. Ek maak dadelik 'n klein aanpassing aan die skema hierbo: die vrystellingsplan is nie 'n maandelikse siklus nie, maar vind 'n paar keer per dag plaas. Daar is 'n paar praktyke gekoppel aan hierdie OS-siklus, waarna ons in meer besonderhede sal kyk.
Belangrik: terugvoer kan 'n oplossing wees vir al die probleme hierbo genoem. Gekombineer met XP-praktyke, kan dit jou uit die afgrond van wanhoop trek.
Hoe om jouself uit die afgrond van wanhoop te trek: drie oefeninge
toetse
Toetse word twee keer in die XP-terugvoerlus genoem. Dit is nie net so nie. Hulle is noodsaaklik vir alle ekstreme programmeringstegnieke.
Daar word aanvaar dat jy Eenheid- en Aanvaardingstoetse het. Sommige gee jou terugvoer binne 'n paar minute, ander oor 'n paar dae, sodat hulle langer neem om te skryf en minder gereeld hardloop.
Daar is 'n klassieke toetspiramide, wat wys dat daar meer toetse behoort te wees.
Hoe is hierdie skema van toepassing op ons in 'n IaC-projek? Eintlik … glad nie.
- Eenheidstoetse, ten spyte van die feit dat daar baie daarvan behoort te wees, kan daar nie baie wees nie. Of hulle toets iets baie indirek. Trouens, ons kan sê dat ons hulle glad nie skryf nie. Maar hier is 'n paar toepassings vir sulke toetse wat ons nog reggekry het:
- Toets kode op jsonnet. Dit is byvoorbeeld ons boupyplyn in hommeltuig, wat redelik ingewikkeld is. Die kode op jsonnet word goed deur toetse gedek.
Ons gebruik dit . - Toetse vir skrifte wat uitgevoer word wanneer die hulpbron begin. Skripte in Python, wat beteken dat toetse daarop geskryf kan word.
- Toets kode op jsonnet. Dit is byvoorbeeld ons boupyplyn in hommeltuig, wat redelik ingewikkeld is. Die kode op jsonnet word goed deur toetse gedek.
- Dit is moontlik moontlik om die konfigurasie in toetse na te gaan, maar ons doen dit nie. Dit is ook moontlik om die kontrolering van hulpbronkonfigurasiereëls deur te konfigureer . Net vir terraform is daar egter te basiese kontrole, maar baie kontroleskrifte word vir AWS geskryf. En ons is op Azure, so dit pas nie weer nie.
- Komponentintegrasietoetse: dit hang af van hoe jy dit klassifiseer en waar jy dit plaas. Maar hulle werk basies.
Dit is hoe integrasietoetse lyk.
Dit is 'n voorbeeld wanneer beelde in Drone CI gebou word. Om hulle te bereik, moet jy 30 minute wag totdat die Packer-beeld saamgestel is, en dan nog 15 minute om te wag totdat hulle verbygaan. Maar hulle is!Beeldverifikasie-algoritme
- Eerstens moet Packer die hele prent voorberei.
- Langs die toets is daar 'n terraform met 'n plaaslike staat, waarmee ons hierdie beeld ontplooi.
- Wanneer dit ontplooi word, word 'n klein module wat langsaan lê, gebruik om dit makliker te maak om met die beeld te werk.
- Wanneer die VM vanaf die prent ontplooi is, kan jy begin kyk. Basies word kontrole op die masjien uitgevoer. Daar word nagegaan hoe die skrifte gewerk het by opstart, hoe die daemone werk. Om dit te doen, via ssh of winrm, gaan ons na die nuut verhoogde masjien en kyk na die status van die konfigurasie of of die dienste gestyg het.
- 'n Soortgelyke situasie met integrasietoetse en modules vir terraform. Hier is 'n kort tabel wat die kenmerke van sulke toetse verduidelik.
Terugvoer oor die pyplyn in die omgewing van 40 minute. Alles neem baie lank. Dit kan vir regressie gebruik word, maar vir nuwe ontwikkeling is dit oor die algemeen onrealisties. As jy baie, baie voorbereid is hiervoor, berei hardloop, skrifte voor, dan kan jy dit tot 10 minute verminder. Maar dit is steeds nie eenheidstoetse nie, wat 5 in 100 sekondes is.
Die gebrek aan eenheidstoetse wanneer beelde of terraform-modules gebou word, moedig die verskuiwing van werk aan na aparte dienste wat eenvoudig via REST getrek kan word, of na Python-skrifte.
Ons moes byvoorbeeld seker maak dat wanneer die virtuele masjien begin, dit homself in die diens registreer , en toe die virtuele masjien vernietig is, het dit homself uitgevee.
Aangesien ons ScaleFT as 'n diens het, word ons gedwing om deur die API daarmee te werk. Daar is 'n omslag geskryf wat jy kan trek en sê: "Kom in en vee hierdie, daardie, daardie uit." Dit stoor al die nodige instellings en toegange.
Ons kan reeds normale toetse hiervoor skryf, aangesien dit geensins verskil van gewone sagteware nie: 'n soort apiha word nat, jy trek, en kyk wat gebeur.
Toetsresultate: Eenheidtoetsing, wat die bedryfstelsel binne 'n minuut moet gee, doen dit nie. En die tipe toetse wat hoër in die piramide is, gee 'n effek, maar sluit net 'n deel van die probleme.
Paar programmering
Toetse is natuurlik goed. Jy kan baie van hulle skryf, hulle kan van verskillende tipes wees. Hulle sal op hul vlakke werk en vir ons terugvoer gee. Maar die probleem met slegte eenheidstoetse wat die vinnigste bedryfstelsel produseer, bly steeds. Terselfdertyd wil ek steeds 'n vinnige bedryfstelsel hê, dit is maklik en aangenaam om daarmee te werk. Om nie te praat van die kwaliteit van die gevolglike oplossing nie. Gelukkig is daar tegnieke om selfs vinniger terugvoer as eenheidstoetse te gee. Dit is paarprogrammering.
Wanneer u kode skryf, wil u so vinnig as moontlik terugvoer oor die kwaliteit daarvan kry. Ja, jy kan alles in 'n kenmerktak skryf (sodat niks aan enigiemand breek nie), 'n trekversoek in die github rig, dit toewys aan iemand wie se mening saak maak, en wag vir 'n antwoord.
Maar jy kan lank wag. Mense is almal besig, en die antwoord, al is daar een, is dalk nie van die hoogste gehalte nie. Gestel die antwoord het dadelik gekom, die resensent het dadelik die hele idee verstaan, maar die antwoord kom steeds laat, agterna. En ek wil iets vroeër hê. Dit is pare-programmering en is daarop gemik - so dadelik, by die skryf hiervan.
Die volgende is die style van paarprogrammering en hul toepaslikheid om aan IaC te werk:
1. Klassiek, Ervare+Ervare, timerverandering. Die twee rolle is bestuurder en navigator. Twee mense. Hulle werk op dieselfde kode en wissel van rolle na 'n sekere voorafbepaalde tydperk.
Oorweeg die verenigbaarheid van ons probleme met styl:
- Probleem: onvolmaaktheid van gereedskap, middele vir kode-ontwikkeling.
Negatiewe impak: dit neem langer om te ontwikkel, ons vertraag, die pas / ritme van werk raak verlore.
Hoe ons veg: ons gebruik 'n ander gereedskap, 'n algemene IDE, en ons leer ook kortpaaie. - Probleem: stadige ontplooiing.
Negatiewe impak: verhoog die tyd om 'n werkende stuk kode te skep. Ons raak verveeld terwyl ons wag, hande reik uit om iets anders te doen terwyl jy wag.
Hoe ons veg: ons het nie oorwin nie. - Probleem: gebrek aan benaderings en praktyke.
Negatiewe invloed: geen kennis van hoe om goed en hoe sleg te doen nie. Brei terugvoer uit.
Hoe ons veg: die uitruil van menings en praktyke in twee-werk los amper die probleem op.
Die grootste probleem met die toepassing van hierdie styl in IaC is die ongelyke tempo van werk. In tradisionele sagteware-ontwikkeling het jy 'n baie eenvormige beweging. Jy kan vyf minute neem om N te skryf. Neem 10 minute om 2N te skryf, 15 minute om 3N te skryf. Hier kan jy vyf minute spandeer en N skryf, en dan nog 30 minute spandeer en 'n tiende van N skryf. Hier weet jy niks, jy het 'n prop, dom. Ontleding neem tyd en lei af van die werklike programmering.
Gevolgtrekking: in sy suiwer vorm pas dit ons nie.
2. Tafeltennis. Hierdie benadering veronderstel dat een deelnemer 'n toets skryf, en die ander maak 'n implementering daarvoor. Met inagneming van die feit dat alles ingewikkeld is met Eenheidstoetse, en jy 'n integrasietoets moet skryf wat lank neem om te programmeer, is al die gemak van tafeltennis weg.
Ek kan sê dat ons die skeiding van pligte probeer het vir die ontwerp van 'n toetsskrif en die implementering van kode daarvoor. Een deelnemer het met 'n draaiboek vorendag gekom, in hierdie deel van die werk was hy verantwoordelik, hy het die laaste woord gehad. En die ander een was verantwoordelik vir die implementering. Dit het goed uitgewerk. Die kwaliteit van die draaiboek met hierdie benadering neem toe.
Gevolgtrekking: helaas, die tempo van werk laat nie die gebruik van tafeltennis as 'n paarprogrammeringspraktyk in IaC toe nie.
3.Sterk styl. . Die idee is dat een deelnemer die aanwysende navigator word en die ander die rol van die uitvoerende bestuurder neem. In hierdie geval is die reg van besluite uitsluitlik vir die navigator. Die bestuurder druk net en die woord kan beïnvloed wat gebeur. Rolle verander nie vir 'n lang tyd nie.
Goed om te leer, maar vereis sterk sagte vaardighede. Hieroor het ons gestruikel. Die tegniek was moeilik. En dit gaan nie net oor infrastruktuur nie.
Gevolgtrekking: potensieel van toepassing, ons gee nie op om te probeer nie.
4. Mobbing, swerm en alle style bekend, maar nie hier gelys nie ons oorweeg nie, want ons het dit nie probeer nie en dit is onmoontlik om daaroor te sê in die konteks van ons werk.
Algemene resultate oor die gebruik van paarprogrammering:
- Ons het 'n ongelyke werktempo wat ons platslaan.
- Ons het onvoldoende goeie sagte vaardighede raakgeloop. En die vakgebied dra nie by om hierdie tekortkominge van ons te oorkom nie.
- Lang toetse, probleme met gereedskap maak paarontwikkeling viskeus.
5. Ten spyte hiervan was daar suksesse. Ons het met ons eie metode "Konvergensie - divergensie" vorendag gekom. Ek sal kortliks beskryf hoe dit werk.
Ons het permanente vennote vir 'n paar dae (minder as 'n week). Ons doen een taak saam. Vir 'n geruime tyd sit ons saam: een skryf, die tweede sit en kyk hoe die ondersteuningspan. Dan skei ons paaie vir 'n rukkie, elkeen doen 'n paar onafhanklike dinge, dan kom ons weer saam, ons sinchroniseer baie vinnig, doen iets saam en skei weer.
Beplanning en kommunikasie
Die laaste blok praktyke waardeur OS-probleme opgelos word, is die organisasie van werk met die take self. Dit sluit ook die uitruil van ervaring in, wat buite paarwerk is. Oorweeg drie praktyke:
1. Take deur die doelboom. Ons het die algehele projekbestuur georganiseer deur 'n boom wat eindeloos die toekoms in strek. Tegnies word die dribbel in Miro gedoen. Daar is een taak - dit is 'n tussendoelwit. Daaruit kom óf kleiner doelwitte óf groepe take. Die take self is van hulle. Alle take word op hierdie bord geskep en onderhou.
Hierdie skema gee ook terugvoer, wat een keer per dag gebeur wanneer ons by saamtrekke sinchroniseer. Om 'n gemeenskaplike plan voor almal te hê, maar tog gestruktureerd en heeltemal oop, laat almal bewus wees van wat gebeur en hoe ver ons gevorder het.
Voordele van visuele visie van take:
- Oorsaaklikheid. Elke taak lei tot een of ander globale doelwit. Take word in kleiner doelwitte gegroepeer. Die infrastruktuurdomein self is redelik tegnies. Dit is nie altyd onmiddellik duidelik watter spesifieke impak dit op die besigheid het nie, byvoorbeeld die skryf van 'n runbook oor die migreer na 'n ander nginx. Deur die teikenkaart langsaan te hê, maak dit meer duidelik.
Oorsaaklikheid is 'n belangrike eienskap van probleme. Dit beantwoord direk die vraag: "Doen ek dit?" - Parallelisme. Daar is nege van ons, en dit is eenvoudig fisies onmoontlik om almal op een taak aan te val. Take van een area is dalk ook nie altyd genoeg nie. Ons word gedwing om parallel te werk tussen klein werkgroepe. Terselfdertyd sit groepe vir 'n geruime tyd op hul taak, hulle kan deur iemand anders versterk word. Uit hierdie werkgroep val mense soms af. Iemand gaan met vakansie, iemand maak 'n verslag vir die DevOps-konferensie, iemand skryf 'n artikel oor Habr. Om te weet watter doelwitte en take parallel gedoen kan word, word baie belangrik.
2. Verwisselbare aanbieders van oggendsaamtrekke. By stand-ups het so 'n probleem geblyk - mense doen baie take parallel. Soms is die take losweg verbind en is daar geen begrip van wie wat doen nie. En die mening van 'n ander lid van die span is baie belangrik. Dit is bykomende inligting wat die verloop van die oplossing van die probleem kan verander. Natuurlik is daar gewoonlik iemand in 'n paar saam met jou, maar raad en wenke is altyd nie oorbodig nie.
Om hierdie situasie te verbeter, het ons die tegniek van "Verandering van die voorste stand-up" toegepas. Nou word hulle volgens 'n sekere lys geroteer, en dit het sy effek. Wanneer dit jou beurt is, moet jy induik en verstaan wat aangaan om 'n goeie skrum-saamtrek te hê.
3. Interne demo. Probleemoplossingshulp van paarprogrammering, taakboomvisualisering en hulp by skrumvergaderings in die oggend is goed, maar nie ideaal nie. As 'n paartjie word julle slegs deur julle kennis beperk. Die taakboom help om wêreldwyd te verstaan wie wat doen. En die gasheer en kollegas by die oggendvergadering sal nie diep in jou probleme duik nie. Hulle kan sekerlik iets mis.
Die oplossing is gevind deur die werk wat aan mekaar gedoen is te demonstreer en dit dan te bespreek. Ons vergader een keer per week vir 'n uur en wys die besonderhede van die oplossings vir die take wat ons die afgelope week gedoen het.
Tydens die demonstrasie is dit nodig om die besonderhede van die taak te openbaar en seker te wees om die werking daarvan te demonstreer.
Die verslag kan volgens die kontrolelys gehou word.1. Tik in konteks. Waar het die taak vandaan gekom, hoekom was dit enigsins nodig?
2. Hoe is die probleem voorheen opgelos? Byvoorbeeld, massa-muisklik was nodig, of dit was onmoontlik om iets te doen.
3. Hoe ons dit verbeter. Byvoorbeeld: "Kyk, nou is daar 'n draaiboek, hier is 'n readme."
4. Wys hoe dit werk. Dit is wenslik om enige gebruikerskrip direk te implementeer. Ek wil X hê, ek doen Y, ek sien Y (of Z). Byvoorbeeld, ontplooi NGINX, rook url, kry 200 OK. As die aksie lank is, berei vooraf voor om later te wys. Dit is raadsaam om nie te breek nie, veral as dit 'n uur voor die demo broos is.
5. Verduidelik hoe suksesvol die probleem opgelos word, watter probleme oorbly, wat nie afgehandel is nie, watter verbeterings in die toekoms moontlik is. Byvoorbeeld, nou cli, dan sal daar volle outomatisering in CI wees.
Dit is wenslik dat elke spreker binne 5-10 minute hou. As jou aanbieding natuurlik belangrik is en langer sal neem, stem dit asseblief vooraf in die sre-oornamekanaal in.
Na die aangesig-tot-aangesig deel is daar altyd 'n bespreking in die draad. Dit is waar die terugvoer wat ons nodig het oor ons take verskyn.
As gevolg hiervan word 'n opname gedoen om die nut van wat gebeur te identifiseer. Dit is reeds terugvoer oor die essensie van die toespraak en die belangrikheid van die taak.
Lang gevolgtrekkings en wat is volgende
Dit mag voorkom asof die toon van die artikel ietwat pessimisties is. Dis verkeerd. Die twee laer vlakke van terugvoer, vasvrae en paarprogrammering, werk. Nie so perfek soos in tradisionele ontwikkeling nie, maar daar is 'n positiewe effek hieruit.
Toetse, in hul huidige vorm, bied slegs gedeeltelike kodedekking. Baie konfigurasiefunksies word nie getoets nie. Hul invloed op die direkte werk by die skryf van kode is laag. Daar is egter 'n effek van integrasietoetse, en dit is hulle wat jou toelaat om vreesloos herfaktorerings uit te voer. Dit is 'n groot prestasie. Ook, met die oordrag van fokus na ontwikkeling in hoëvlaktale (ons het luislang, gaan), gaan die probleem weg. En jy het nie baie tjeks vir "gom" nodig nie, 'n algemene integrasie een is genoeg.
Om in pare te werk is meer afhanklik van spesifieke mense. Daar is 'n taakfaktor en ons sagte vaardighede. Sommige is baie goed, sommige is erger. Daar is beslis 'n voordeel hieraan. Dit is duidelik dat selfs met onvoldoende nakoming van die reëls van paarwerk, die feit van gesamentlike uitvoering van take 'n positiewe uitwerking op die kwaliteit van die resultaat het. Persoonlik vind ek dit makliker en aangenamer om in pare te werk.
Hoërvlak maniere om die OS te beïnvloed - beplanning en werk met take gee presies effekte: 'n kwaliteit uitruil van kennis en 'n verbetering in die kwaliteit van ontwikkeling.
Kort gevolgtrekkings in een reël
- XP-praktyke werk in IaC, maar met minder doeltreffendheid.
- Versterk wat werk.
- Kom met jou eie kompenserende meganismes en praktyke.
Bron: will.com