Chceli by sme, aby proces zahŕňal veci ako toto do našich požiadaviek na stiahnutie bez toho, aby sme skutočne zahltili zdrojový kód našej aplikácie kódom SQL. Našou počiatočnou myšlienkou bolo spomenúť, aké zmeny SQL je potrebné skontrolovať v komentároch žiadosti o stiahnutie, ale zaujíma nás, či existuje lepší spôsob.
Ako ste videli, že položky bez kódu, ako je táto, sú zahrnuté do recenzií kódu, ku ktorým dochádza pri žiadostiach o stiahnutie? Existuje "dobrý" spôsob, ako to urobiť?
Uložené procedúry sú určite kód. DDL je pravdepodobne kód.
V súčasnosti máme (rôzne projekty) konfiguračné súbory poštára (testovacie a dev referencie pre užívateľov na palube), README.md (a ďalšie súbory md) a ďalšie súbory ako doplnková dokumentácia (.html, .txt a .yaml na rôzne účely), konfiguračné súbory env (pravdepodobne kód), súbory CI/CD .rc (tiež pravdepodobne kód).
Na účely balenia knižnice tiež odovzdávame automaticky generovaný kód. Fuj.
Trik je v tom, aby ste sa uistili, že artefakty „na kontrolu“ sa dajú ľahko rozlíšiť od „kontrola nie je potrebná“ (vygenerované súbory, ako sú súbory .dmp db)
Nie som si istý, či úplne dodržiavam tento kúsok. Ak sa tieto zmeny dajú zobraziť na nejakej URL pri požiadavke na vytiahnutie je vytvorený, potom stačí pridať odkaz.svdsinner povedal:Aj keď sa samotné zmeny databázy sledujú v samostatnom úložisku GIT, nie sú súčasťou požiadavky na stiahnutie. (Sú automaticky potvrdené, keď proces zistí, že zmeny boli vykonané v databáze)
Kliknutím rozbalíte...
Ale niečo na tom, že sa tieto zmeny automaticky vykonajú v inom repo, mi vadí. Buď sú zadaní predtým preskúmané PR je urobené (znie to zle? zlučujete kód súvisiaci s PR, ktorý ešte nebol schválený?), alebo nie sú potvrdené pri vytváraní PR (ako by teda niekto mohol testovať PR na posúdenie?).
Poviem niečo kontroverzné: veľa bolesti pochádza z uchovávania vecí v samostatných repozitároch, keď by tieto veci nemali byť v samostatných repozitároch (väčšinou: chcete urobiť atómové zmeny...).
Poviem, že asi 2 % mojich žiadostí o stiahnutie sú cross-repo. Sú na rovnakom serveri gitlab, ale napriek tomu neexistuje spôsob, ako koordinovať zmeny. Ešte horšie je, keď rôzne repozitáre vlastnia rôzni ľudia. Moje pozorovanie je, že každý len vykoná svoj súbor zmien bez toho, aby predtým niečo skutočne skontroloval. Ak sa pokazí, povedia mi, aby som to aj tak opravil, rovnako ako za starých čias pred CI.koala povedala:Poviem niečo kontroverzné: veľa bolesti pochádza z uchovávania vecí v samostatných repozitároch, keď by tieto veci nemali byť v samostatných repozitároch (väčšinou: chcete urobiť atómové zmeny...).
Kliknutím rozbalíte...
Takže to je niečo, čo mi na svn chýba. Mohli ste si pozrieť podstrom alebo podstrom atď., takže bolo rozumnejšie mať veľa vecí v tom istom repo. Za predpokladu, že ste vedeli, s čím sa budete pohrávať, skontrolujete najmenší podstrom, ktorý pokrýva všetky vaše zmeny, a vaše kontroly by boli atómové.
Neviem. Myslím si, že prechod na monorepo je ťažký a pravdepodobne je tu veľa problémov. Nikdy som nedokázal takto pracovať. Všetko, čo viem, sú bolesti pri vykonávaní zmien v lockstep na rôznych repo.
Väčšina obhajoby manyrepos, ktorú vidím, je buď úplne nesprávna, alebo neplatí v rozsahu, v akom pracujem (väčšinou malé tímy vývojárov). Existuje dobrá opodstatnená kritika monorepo, ale je zvláštne, že to robí veľa trendových ľudí, no mnohí sú proti tomu...
100% toto. Z dôvodov máme samostatné úložisko migrácií, do ktorého idú všetky zmeny DB: úprava schémy, úprava uložené procedúry, dokonca aj niektoré jednorazové aktualizácie údajov (napr.: zvykli sme ukladať niektoré časy v UTC a niektoré v lokálny server; keď sme všetko presunuli do UTC, spustili sme migráciu na aktualizáciu všetkých starých miestnych časových pečiatok servera na UTC).Jehos povedal:Uložené procedúry sú určite kód. DDL je pravdepodobne kód.
Kliknutím rozbalíte...
Proces nasadenia spustí aplikáciu, ktorá požiada cieľovú DB (prod/stage/...) na git hash posledného úspešného spustenia a potom nájde všetky súbory ktoré boli po tomto hashove upravené (na príslušnej vetve – každé prostredie má svoje) a logicky ich spája do jedného obra transakcia len s trochou logiky, aby ste sa uistili, že podpriečinky sú spustené v správnom poradí (napr.: aktualizácia schémy pred uloženou procedúrou aktualizácie). Transakcia končí aktualizáciou hashu „posledného spustenia“ v DB. Stále sa snažíme, aby bolo všetko idempotentné, pre prípad, že by sa niečo zadrhlo.
Lístky často obsahujú viacero PR: jednu pre aplikáciu (a!) a jednu pre DB, čo nie je ideálne, ale jedno vs. viacnásobné repozitáre je úplne iná otázka. (a zdá sa, že viacnásobné repozitáre budú pre nás aj naďalej vhodné, s niekoľkými vývojárskymi tímami a množstvom práce vloženej do automatizácie vydaní na aplikáciu/repo).
Jehos povedal:Uložené procedúry sú určite kód. DDL je pravdepodobne kód.
Kliknutím rozbalíte...
Toto.
Tiež by som sa spýtal, prečo sú definície databázových schém umiestnené v inom úložisku ako aplikácie [0], ktoré schému využívajú. Všetky doteraz uvedené dôvody mi znejú ako zlé, ak vezmeme do úvahy, že veci môžete jednoducho vkladať do rôznych podstromov a vykonávať čiastočné kontroly.
[0] Nemusíte ísť do úplného mono-repo, ale ak ste v situácii, keď je databáza vaša API medzi aplikáciami (a ak máte viacero aplikácií, ktoré pristupujú k rovnakej schéme DB, vaše DB je API), tieto aplikácie by mali ísť do rovnakého repo.
Takáto vec veľmi závisí od nástrojov. V ideálnom prípade by ste mali nejaký druh systému správy závislostí, ako je Maven (ale nezávislý na jazyku), ktorý sleduje zdrojové verzie použité na zostavenie každej verzie balíka a potom niekoľko nástrojov na kontrolu týchto úložísk na konkrétnom mieste verzia. Pridajte to k niekoľkým krížovým adresárovým príkazom git, ktorý dokáže spustiť git vo viacerých adresároch naraz, aby ste mohli napr. napríklad vytvorte odovzdanie v desiatich úložiskách súčasne a použitie tucta alebo dvoch mikroúložísk je pekné ľahké. Ale ak vám chýba jeden z týchto nástrojov, potom to robí veci naozaj ťažkými, čo v skutočnosti znamená, že by ste mali prísť na to, ako tieto nástroje napísať.dažďový tieň povedal:To je pravda, ale nezdalo sa, že by to ovplyvnilo moje rozhodnutie rôznych spolupracovníkov na vyššej úrovni vytvoriť doslova stovky malých projektov, keď prešli na git. Myslím si, že sa viac zaujímali o manažérske veci, ako je spolitizovanie, kto sa stane vlastníkom a správcom. Som skôr plavák, takže naše predchádzajúce nastavenie (len dve veľké svn repo) mi lepšie vyhovovalo. Svet však nie je o mne, takže...áno.
Kliknutím rozbalíte...
Edit: Tiež stojí za zmienku: aj keď máte mono-repo, naozaj stále potrebujete podobný nástroj podobný Maven na správu mikroslužieb. Koniec koncov, väčšina nasadení zahŕňa viacero zostáv, ktoré môžu byť z rôznych dôvodov vytvorené z viacerých vetiev vášho mono-repo. Takže, keď sa niečo pokazí, stále potrebujete nejaký nástroj na kontrolu toho, čo je aktuálne nasadené v produkcii, čo znamená nástroj podobný Mavenovi na sledovanie zdrojových verzií pre každú zostavu artefakt. Bez takéhoto nástroja môžete mať menšiu bolesť, ak máte mono-repo, ale mono-repo v skutočnosti úplne nerieši daný problém.
Stačí vytvoriť dočasnú vetvu a zlúčiť do nej všetko, čo potrebujete. Netreba veci komplikovať.
Ak je toto najpresvedčivejší príklad budovania vecí z viacerých vetiev, potom si myslím, že väčšina ľudí by sa tým nemala obávať.
To je nanič a vyžaduje si to veľa nástrojov a bolesti. Ale pre trvalú je to nevyhnutné.
Nemusíte ísť do mono repo, ale mali by ste mať tak málo, koľko potrebujete na oddelenie vecí, ktoré buď úplne nesúvisia, alebo sú potrebné kvôli povoleniam (všimnite si, že môžete vyriešiť vlastníctvo na subrepo úrovni s vecami ako CODEOWNERS, ak to naozaj potrebujete).
Ak sa snažíte pristupovať k veciam z perspektívy „ako Amazon“[1], aplikácia vlastní svoju databázu/zálohu store a nikto iny sa toho priamo nedotkne, tak vlozit db kod do ineho repo je uplny anti vzor.
Preto si myslím, že najcennejšou architektonickou zmenou, ktorú by ste tu mohli urobiť, nie je zlepšiť fungovanie viacerých repo, ale zabezpečiť, aby vaša „jednotka práce“ na vykonanie zmeny zahŕňala iba jedno repo
1. Myslím si, že Amazon bol šikovný, keď pristupoval k podporným obchodom týmto spôsobom, a platí to v mierkach oveľa menších, ako Amazon je alebo bol v čase, keď to robili.
Obmedzenie prezerania si absolútne vyžaduje technické riešenia, ale znamená to samostatné úložiská, ako som povedal. Ak si ľudia myslia, že získajú lepšie „vlastníctvo“ (zvyčajne synonymum pre kontrolu zmien niečoho IME), potom CODEOWNERS to absolútne zabezpečuje bez toho, aby vyžadovali samostatné úložiská.
V každom prípade si tiež myslím, že vo väčšine organizácií jediné, čo by ste mali urobiť, je skutočne presadiť v softvéri, aby ľudia nemohli prepisovať históriu v pobočkách, ktoré sú nasadené do výroby. To znamená, že ľudia nemôžu robiť „škodlivé“ veci. Domnievam sa, že „nesprávne“ veci (napríklad zlúčenie vecí bez dodržiavania dohôd) by mali byť skôr „spoločenskou dohodou“ ako pravidlom vynúteným softvérom. Ak naozaj potrebujete to automatické presadzovanie... no, myslím si, že „úroveň dôvery“ vo vašej organizácii je niečo, čo treba riešiť.
(Okrem nariadení, ktoré musíte skutočne dodržiavať, a prostredí, kde môžu byť obrovské stimuly robiť škodlivé veci, ktoré môžu príliš dlho nepozorovane prekĺznuť, kým sa to dá dobre vrátiť späť.)
Som rád, že nemôžem presadzovať zmeny priamo k majstrovi. Je to ľahká chyba a nepríjemná vec pre sto ďalších ľudí (ak by vaše zmeny zlyhali napríklad pri kontrolách CI)
Ako som už spomenul, sú pravdepodobné prípady, keď nie každému by malo byť umožnené vidieť všetko, áno. Ale veľká časť z nich sa mýli – zatiaľ čo ďalšia časť je správna. Ak sa musí presadzovať len pre vaše oči, zvážil by som použitie Copybary alebo niečoho podobného, pričom by som v zákulisí umožnil väčšie monorepo.
(Nehovorte to môjmu zamestnávateľovi, ale zašiel som tak ďaleko, že som upravil skripty CI v pobočke, aby som urobil úplné zostavenie, a potom som to vrátil pred vykonaním požiadavky na stiahnutie.)
Ako funguje pobočka CI/CD na miestach vášho zamestnania?
Vykonávame (veľkú) podmnožinu kontrol proti pobočkám. Je to niekoľko stoviek hodín výpočtov na pobočku (paralelne), takže to nie sú triviálne náklady.
Máme pod tím, ktorý to celé udržiava v chode, sú skvelí.
A dokonca by vám nemalo byť dovolené zlúčiť sa bez absolvovania testov a úspešných zostavení!dažďový tieň povedal:Postup, ktorý by som rád videl viac, je, že pobočky robia rovnaké CI/CD/automatické QA ako master, s výnimkou skutočnej inštalácie do produkcie na konci. Už by ste mali vedieť, či niečo prejde predtým zlúčenie.
Kliknutím rozbalíte...
V minulosti som pracoval na projektoch, kde testovanie plnej integrácie predstavovalo obrovské úsilie (časovo aj výpočtovo) a robilo sa len ako predpoklad skutočného nasadenia UAT/produkcie. Myslím si, že vyrezanie niečoho takého z odvetvia CI/CD môže byť prijateľné pragmatické rozhodnutie.
Úprimne povedané, toto všetko je dosť tvrdá ihla na správne navliekanie. Naozaj potrebujete rovnováhu:
- Rýchle stavanie
- Rýchly testovací cyklus
- Zmysluplné testy
A späť k danej téme – uprednostňujem, aby bolo VŠETKO zahrnuté v tom istom repo (a teda PR): kód aplikácie, kód infraštruktúry, kód databázy a konfigurácia. Dobré nástroje môžu pomôcť, aby to bolo lepšie zvládnuteľné, ale nie je to kúzlo. Dokonca aj vo vysoko regulovaných prostrediach (napríklad tam, kde tá istá osoba nemôže napísať kód a nasadiť do výroby) túto stratégiu možno často použiť, ak sa zavedú vhodné kontroly a audit.
