Traduzzione di l'articulu preparatu per i studienti di u cursu "Pratiche è strumenti DevOps" in u prughjettu educativu OTUS.

Duvete sceglie un monorepository perchè u cumpurtamentu chì prumove in i vostri squadre hè a trasparenza è a rispunsabilità cumuna, soprattuttu cum'è e squadre crescenu. In ogni modu, avete da invistisce in l'uttellu, ma hè sempre megliu se u cumpurtamentu predeterminatu hè u cumpurtamentu chì vulete in i vostri cumandamenti.

Perchè parlemu di questu?

Matt Klein hà scrittu l'articulu "Monorepos: Per piacè ùn fate micca!"  (nota di u traduttore: traduzzione nantu à Habré "Monorepositori: per piacè ùn fate micca"). Mi piace Matt, pensu chì hè assai intelligente è duvete leghje u so puntu di vista. In origine hà publicatu u sondaghju in Twitter:

Traduzione:
Questu ghjornu di l'annu novu, discuteraghju quantu ridiculi sò i monorepositori. 2019 hà cuminciatu tranquillamente. In u spiritu di questu, vi offre un sondaghju. Quale sò i grandi fanatichi ? Sustenituri:
- Monorepo
- Rust
- Sondaggio incorrettu / tramindui

A mo risposta hè stata: "Sò literalmente e duie persone". Invece di parlà di cumu Rust hè una droga, fighjemu perchè pensu chì hè sbagliatu nantu à i monorepositori. Un pocu di sè stessu. Sò u CTO di Chef Software. Avemu circa 100 ingegneri, una basa di codice chì torna circa 11-12 anni, è 4 prudutti principali. Qualchidunu di stu codice hè in un polyrepository (a mo pusizioni di partenza), alcuni hè in un monorepository (a mo pusizione attuale).

Prima di principià: ogni argumentu chì faraghju quì s'applicà à i dui tipi di repositori. In u mo parè, ùn ci hè micca un mutivu tecnicu perchè duvete sceglie un tipu di repository sopra un altru. Pudete fà u travagliu di ogni approcciu. Sò cuntentu di parlà, ma ùn sò micca interessatu à ragiuni tecnichi artificiali perchè unu hè superiore à l'altru.

Sò d'accordu cù a prima parte di u puntu di Matt:

Perchè à scala, un monorepositoriu risolverà tutti i stessi prublemi chì un polirepositoriu risolve, ma à u stessu tempu furzendu à coppià strettamente u vostru codice è esigendu sforzi incredibili per aumentà a scalabilità di u vostru sistema di cuntrollu di versione.

Averete da risolve i stessi prublemi, indipendentemente da se sceglite un monorepository o un polyrepository. Cumu liberate e versioni? Chì ghjè u vostru approcciu à l'aghjurnamenti? Cumpatibilità retrocede? Dipendenze incruciate di u prugettu? Chì stili architetturali sò accettati? Cumu gestisce a vostra infrastruttura di costruzione è teste? A lista hè infinita. È li risolverete tutti mentre cresce. Ùn ci hè micca furmagliu liberu.

Pensu chì l'argumentu di Matt hè simile à i punti di vista spartuti da parechji ingegneri (è amministratori) chì rispettu. Questu accade da a perspettiva di l'ingegnere chì travaglia nantu à u cumpunente o a squadra chì travaglia nantu à u cumpunente. Avete intesu cose cum'è:

• A basa di codice hè voluminosa - ùn aghju micca bisognu di tuttu stu junk.
• Hè più difficiuli di pruvà perchè aghju da pruvà tuttu questu junk chì ùn aghju micca bisognu.
• Hè più difficiuli di travaglià cù dipendenze esterne.
• Aghju bisognu di i mo propri sistemi di cuntrollu di versione virtuale.

Di sicuru, tutti sti punti sò ghjustificate. Questu succede in i dui casi - in u polyrepository aghju u mo propiu junk, in più di quellu chì hè necessariu per a custruzzione... Puderaghju ancu bisognu di altre junk. Allora aghju "simplicemente" creà strumenti chì verificanu tuttu u prughjettu. O creanu un falsu monorepository cù submoduli. Pudemu caminari intornu à questu tuttu u ghjornu. Ma pensu chì l'argumentu di Matt manca u mutivu principalu, chì aghju cambiatu assai in favore di u monorepository:

Provoca a cumunicazione è mostra i prublemi

Quandu avemu separatu i repositori, creamu un prublema di facto di coordinazione è trasparenza. Questu currisponde à a manera di pensà à e squadre (in particulare a manera chì i membri individuali pensanu à elli): simu rispunsevuli di un certu cumpunente. Travagliemu in un isolatu relative. I cunfini sò fissi nantu à a mo squadra è i cumpunenti (s) chì avemu travagliatu.

Quandu l'architettura diventa più cumplessa, una squadra ùn pò più gestisce sola. Pochi ingegneri anu tuttu u sistema in a so testa. Diciamu chì gestite un cumpunente cumunu A chì hè utilizatu da i Teams B, C è D. L'equipa A hè refactoring, migliurà l'API, è ancu cambià l'implementazione interna. In u risultatu, i cambiamenti ùn sò micca retrocompatibili. Chì cunsigliu avete ?

• Truvate tutti i posti induve l'antica API hè utilizata.
• Ci hè un locu induve a nova API ùn pò esse usata?
• Pudete riparà è pruvà altri cumpunenti per assicurà chì ùn si rompenu?
• Queste squadre ponu pruvà i vostri cambiamenti avà?

Per piacè nutate chì queste dumande sò indipendenti da u tipu di repository. Avete bisognu di truvà squadre B, C è D. Avete bisognu di parlà cun elli, scopre u tempu, capisce e so priurità. Almenu speremu chì sì.

Nimu ùn vole veramente fà questu. Questu hè assai menu divertente ch'è solu di riparà a maledetta API. Hè tuttu umanu è disordinatu. In un polyrepository, pudete solu fà cambiamenti, dà à e persone chì travaglianu in quellu cumpunente (probabilmente micca B, C o D) per rivisione, è andate avanti. E squadre B, C è D ponu solu stà cù a so versione attuale per avà. Seranu rinnuvati quandu si capiscenu u vostru geniu!

In un monorepository, a rispunsabilità hè cambiata per automaticamente. A squadra A cambia u so cumpunente è, s'ellu ùn hè micca attentu, rompe immediatamente B, C è D. Questu porta à B, C è D chì si prisentanu à a porta di A, dumandendu perchè a squadra A hà rottu l'assemblea. Questu insegna à A chì ùn ponu micca saltà a mo lista sopra. Hanu da parlà di ciò chì anu da fà. B, C è D ponu move ? E se B è C ponu, ma D era strettamente ligata à un effettu secundariu di u cumpurtamentu di l'algoritmu anticu?

Allora avemu da parlà di cumu esce da sta situazione:

1. Supportu per parechje API interni, è marcarà u vechju algoritmu cum'è obsoletu finu à chì D pò cessà di usà.
2. Supportu per parechje versioni di liberazione, una cù a vechja interfaccia, una cù a nova.
3. Ritardà a liberazione di i cambiamenti di A finu à chì B, C è D ponu accettà simultaneamente.

Dicemu chì avemu sceltu 1, parechje API. In questu casu avemu dui pezzi di codice. Vechju è novu. Piuttostu còmuda in certi situazioni. Cuntrollamu u vechju codice in daretu, marcatu deprecated, è accunsenu un schedariu di rimuzione cù a squadra D Essenzialmente identica per i repositori poli è mono.

Per liberà parechje versioni, avemu bisognu di un ramu. Avà avemu dui cumpunenti - A1 è A2. E squadre B è C usanu A2 è D usa A1. Avemu bisognu chì ogni cumpunente sia prontu per a liberazione perchè l'aghjurnamenti di sicurezza è altre correzioni di bug ponu esse richiesti prima di D pò avanzà. In un polyrepository, pudemu ammuccià questu in un ramu longu chì si senti bè. In un monorepository, forzemu u codice per esse creatu in un novu modulu. L'equipa D duverà ancu fà cambiamenti à u cumpunente "vechju". Tutti ponu vede u costu chì paghemu quì - avemu avà duie volte più codice, è qualsiasi correzione di bug chì si applica à A1 è A2 deve applicà à tutti dui. Cù l'approcciu di ramificazione in un polyrepository, questu hè oculatu daretu à a ciliegia. Cunsideremu chì u costu hè più bassu perchè ùn ci hè micca duplicazione. Da un puntu di vista praticu, u costu hè u listessu: custruite, liberate è mantene duie codebase largamente identiche finu à chì pudete sguassà unu di elli. A diferenza hè chì cù un monorepository stu dulore hè direttu è visibile. Questu hè ancu peghju, è questu hè bonu.

Infine, avemu ghjuntu à u terzu puntu. ritardu di liberazione. Hè pussibule chì i cambiamenti fatti da A migliurà a vita di u Team A. Impurtante, ma micca urgente. Pudemu solu ritardà ? In un polyrepository, spingemu questu per pinà l'artefattu. Di sicuru, avemu dettu questu à u Team D. Basta à stà nantu à a versione vechja finu à chì vi ghjunghje ! Questu vi mette à ghjucà à u vigliu. L'equipa A cuntinueghja à travaglià nantu à u so cumpunente, ignorendu u fattu chì a squadra D usa una versione sempre più obsoleta (hè u prublema di a squadra D, sò stupidi). Intantu, a squadra D parla pocu di l'attitudine trascurata di a squadra A versu a stabilità di u codice, s'ellu ne parlanu. I mesi passanu. Finalmente, u Team D decide di guardà a pussibilità di un aghjurnamentu, ma A solu hà più cambiamenti. L'equipa A s'arricorda appena quandu o cumu si rumpianu D. L'aghjurnamentu hè più doloroso è duverà più. Chì l'invia più in basso in a pila di priorità. Finu à u ghjornu chì avemu un prublema di sicurità in A chì ci obliga à fà un ramu. A squadra A deve retrocede in u tempu, truvà un puntu quandu D era stabile, risolve u prublema quì, è rende pronta per a liberazione. Questa hè a scelta de facto chì a ghjente face, è hè di granu u peghju. Sembra esse bonu per u Team A è u Team D, sempre chì pudemu ignurà l'altru.

In un monorepository, u terzu ùn hè micca veramente una opzione. Sò furzati à trattà a situazione in unu di dui modi. Avete bisognu di vede i costi di avè dui rami di liberazione. Amparate à prutezzione di l'aghjurnamenti chì rompenu a cumpatibilità retroattiva. Ma u più impurtante: ùn pudete micca evità di avè una conversazione difficiule.

In a mo sperienza, quandu e squadre diventanu grandi, ùn hè più pussibule di mantene tuttu u sistema in mente, è questu hè a parte più impurtante. Duvete migliurà a visibilità di a discordia in u sistema. Avete bisognu di travaglià attivamente per fà chì e squadre si alluntanassi da i so cumpunenti è fighjà u travagliu di l'altri squadre è i cunsumatori.

Iè, pudete creà strumenti chì pruvate à risolve u prublema di u polirepositoriu. Ma a mo sperienza insegnà a consegna cuntinuu è l'automatizazione in grandi imprese mi dice questu: u cumpurtamentu predeterminatu senza l'usu di strumenti supplementari hè u cumpurtamentu chì aspettate di vede. U cumpurtamentu predeterminatu di un polirepositoriu hè l'isolamentu, questu hè u puntu tutale. U cumpurtamentu predeterminatu di un monorepository hè rispunsabilità è trasparenza spartuti, questu hè u puntu tutale. In i dui casi, aghju da creà un strumentu chì lisciarà i bordi aspri. Cum'è un capu, sceglieraghju un monorepositoriu ogni volta perchè l'arnesi anu bisognu di rinfurzà a cultura chì vogliu, è a cultura vene da piccule decisioni è u travagliu di u ghjornu di a squadra.

Solu l'utilizatori registrati ponu participà à l'indagine. Firmà lu, per piacè.

Quale sò i più grandi fanatici? Sustenituri:

• Monorepo

• Rust

• Sondaggio incorrettu / tramindui

33 utilizatori anu vutatu. 13 utilizatori si sò astenuti.

Source: www.habr.com