Vertaling van die artikel wat voorberei is vir studente van die kursus "DevOps-praktyke en gereedskap" in die opvoedkundige projek OTUS.

Jy moet 'n monorepo kies, want die gedrag wat dit in jou spanne bevorder, is deursigtigheid en gedeelde verantwoordelikheid, veral namate spanne groei. Hoe dit ook al sy, jy sal in gereedskap moet belê, maar dit is altyd beter as die standaardgedrag die gedrag is wat jy in jou opdragte wil sien.

Hoekom praat ons hieroor?

Matt Klein het 'n artikel geskryf Monorepos: Moet asseblief nie!  (vertalersnota: vertaling op Habré "Monorepositories: moet asseblief nie"). Ek hou van Matt, ek dink hy is baie slim en jy moet sy standpunt lees. Hy het oorspronklik die meningspeiling op Twitter geplaas:

Vertaling:
Hierdie Nuwejaarsdag gaan ek stry oor hoe belaglik monorepositories is. 2019 het sonder gebeure begin. In die gees hiervan bied ek u 'n opname aan. Wie is die groot fanatici? Ondersteuners:
- Monorepositories
- Rust
- Verkeerde peiling / albei

My antwoord was: "Ek is letterlik albei daardie mense." In plaas daarvan om te praat oor watter soort dwelm Rust is, kom ons kyk hoekom ek dink hy is verkeerd oor monorepositories. 'n Bietjie oor jouself. Ek is die CTO van Chef Software. Ons het ongeveer 100 ingenieurs, 'n kodebasis van ongeveer 11-12 jaar, en 4 kernprodukte. Sommige van hierdie kode is in die polyrepository (my beginposisie), sommige is in die monorepository (my huidige posisie).

Voordat ek begin: elke argument wat ek hier maak, sal van toepassing wees op beide soorte bewaarplekke. Na my mening is daar geen tegniese rede waarom jy die een of die ander tipe bewaarplek moet kies nie. Jy kan enige benadering laat werk. Ek praat graag daaroor, maar ek stel nie belang in kunsmatige tegniese redes waarom die een beter is as die ander nie.

Ek stem saam met die eerste deel van Matt se punt:

Want op groot skaal sal 'n monorepo al dieselfde probleme oplos wat 'n polyrepository oplos, maar terselfdertyd uitlok jou om jou kode styf te koppel en vereis ongelooflike pogings om die skaalbaarheid van jou weergawebeheerstelsel te verhoog.

Jy moet dieselfde probleme oplos, ongeag of jy 'n monorepository of 'n polyrepository kies. Hoe stel jy vrystellings vry? Wat is jou benadering tot opdaterings? Terugwaartse versoenbaarheid? Kruis projek afhanklikhede? Watter argitektoniese style is aanvaarbaar? Hoe bestuur jy jou bou- en toetsinfrastruktuur? Die lys is eindeloos. En jy sal hulle almal oplos soos jy groei. Daar is geen gratis kaas nie.

Ek dink Matt se argument is soortgelyk aan die sienings wat deur baie ingenieurs (en bestuurders) gedeel word wat ek respekteer. Dit is vanuit die perspektief van die ingenieur wat aan die komponent werk, of die span wat aan die komponent werk. Jy hoor dinge soos:

• Die kodebasis is omslagtig - ek het nie al hierdie gemors nodig nie.
• Dit is moeiliker om te toets, want ek moet al hierdie kak wat ek nie nodig het nie, toets.
• Dit is moeiliker om met eksterne afhanklikhede te werk.
• Ek benodig my eie virtuele weergawebeheerstelsels.

Natuurlik is al hierdie punte geregverdig. Dit gebeur in beide gevalle - ek het my eie rommel in die polyrepository, bykomend tot wat nodig is vir die bou ... Ek het dalk ander rommel nodig. Daarom skep ek "net" gereedskap wat die hele projek afreken. Of ek skep 'n vals monorepo met submodules. Ons kon heeldag hier rondom stap. Maar ek dink Matt se argument mis die hoofrede, wat ek nogal omgedraai het ten gunste van 'n monorepo:

Dit lok kommunikasie uit en toon probleme

Wanneer ons bewaarplekke skei, skep ons 'n de facto-probleem van koördinasie en deursigtigheid. Dit is in lyn met hoe ons oor spanne dink (veral hoe individuele lede oor hulle dink): ons is verantwoordelik vir 'n sekere komponent. Ons werk in relatiewe isolasie. Die perke is vasgestel op my span en die komponent(e) waaraan ons werk.

Soos die argitektuur meer kompleks word, kan een span dit nie meer alleen bestuur nie. Baie min ingenieurs hou die hele stelsel in hul kop. Kom ons sê jy bestuur 'n gedeelde komponent A wat deur spanne B, C en D gebruik word. Span A is besig om te herfaktoreer, die API te verbeter en die interne implementering te verander. Gevolglik is die veranderinge nie terugwaarts versoenbaar nie. Watter raad sal jy gee?

• Vind alle plekke waar die ou API gebruik word.
• Is daar plekke waar die nuwe API nie gebruik kan word nie?
• Kan jy ander komponente regmaak en toets om seker te maak hulle breek nie?
• Kan hierdie opdragte jou veranderinge nou toets?

Let daarop dat hierdie vrae onafhanklik is van die tipe bewaarplek. Jy sal spanne B, C en D moet vind. Jy sal met hulle moet praat, die tyd moet uitvind, hul prioriteite moet verstaan. Ten minste hoop ons jy doen.

Om die waarheid te sê, niemand wil dit doen nie. Dit is baie minder pret as om net 'n verdomde API reg te maak. Dit alles is menslik en verwarrend. In 'n polyrepository kan jy net veranderinge aanbring, dit laat hersien deur diegene wat aan daardie komponent werk (waarskynlik nie B, C of D nie), en aanbeweeg. Spanne B, C en D kan vir eers net op hul huidige weergawe bly. Hulle sal opgradeer wanneer hulle jou genialiteit besef!

In 'n monobewaarplek word verantwoordelikheid by verstek verskuif. Span A verander hul komponent en, indien nie versigtig nie, breek dadelik B, C en D. Dit lei daartoe dat B, C en D by A se deur opdaag en wonder hoekom Span A die samestelling verbreek het. Dit leer A dat hulle nie my lys hierbo kan oorslaan nie. Hulle moet praat oor wat hulle gaan doen. Kan B, C en D beweeg? Wat as B en C kan, maar D was nou verwant aan 'n newe-effek van die gedrag van die ou algoritme?

Dan moet ons praat oor hoe ons uit hierdie situasie sal kom:

1. Ondersteuning vir verskeie interne API's, met die ou algoritme afgekeur totdat D dit kan ophou gebruik.
2. Ondersteuning vir verskeie weergawes, een met die ou koppelvlak, een met die nuwe een.
3. Deur die vrystelling van A se veranderinge uit te stel totdat B, C en D dit almal op dieselfde tyd kan aanvaar.

Kom ons sê ons het 1, veelvuldige API's gekies. In hierdie geval het ons twee stukke kode. Oud en nuut. In sommige situasies redelik handig. Ons stel die ou kode terug, merk dit as afgekeur en skeduleer die verwydering daarvan met die D-span. In wese identies vir poly en mono.

Om veelvuldige weergawes vry te stel, benodig ons 'n tak. Nou het ons twee komponente - A1 en A2. Spanne B en C gebruik A2 en D gebruik A1. Ons het elke komponent nodig om gereed te wees vir vrystelling omdat sekuriteitsopdaterings en ander foutoplossings nodig mag wees voordat D kan aanbeweeg. In 'n polyrepository kan ons dit opberg in 'n langlewende tak wat goed voel. In 'n monorepository dwing ons kode in 'n nuwe module. Span D sal steeds veranderinge aan die "ou" komponent moet aanbring. Almal kan die koste sien wat ons hier betaal – ons het nou twee keer soveel kode, en enige foutoplossings wat op A1 en A2 van toepassing is, behoort op albei van toepassing te wees. Met die benadering om takke in 'n polyrepository te gebruik, is dit weggesteek agter 'n kersie-pluk. Ons beskou die koste as minder omdat daar geen duplisering is nie. As 'n praktiese saak is die koste dieselfde: jy sal twee basies identiese kodebasisse bou, vrystel en in stand hou totdat jy een van hulle kan verwyder. Die verskil is dat in 'n mono-bewaarplek hierdie pyn direk en sigbaar is. Dit is erger, en dit is goed.

Uiteindelik het ons by die derde punt gekom. Vrystelling vertraging. Dit is moontlik dat veranderings wat deur A gemaak word, die lewens van span A sal verbeter. Belangrik, maar nie dringend nie. Kan ons maar uitstel? In die polyrepository druk ons ​​dit om die artefak vas te pen. Natuurlik praat ons hieroor met die D-span. Bly net op die ou weergawe totdat jy inhaal! Dit stel jou in staat om die lafaard te speel. Span A gaan voort om aan hul komponent te werk, en ignoreer die feit dat Span D 'n toenemend verouderde weergawe gebruik (dit is Span D se probleem, hulle is dom). Intussen praat Span D sleg oor Span A se onverskillige houding jeens kodestabiliteit, as hulle enigsins daaroor praat. Maande gaan verby. Uiteindelik besluit die D-span om na die moontlikheid van opgradering te kyk, maar die veranderinge in A het net meer geword. Span A onthou skaars wanneer en hoe hulle D gebreek het. Die opgradering is pynliker en sal langer neem. Wat dit verder in die prioriteitstapel afstuur. Tot die dag dat ons 'n sekuriteitskwessie in A het wat ons dwing om te tak. Span A moet teruggaan in tyd, 'n punt vind waar D stabiel was, die probleem daar regmaak en dit gereed maak vir vrystelling. Dit is die de facto keuse wat mense maak, en verreweg die ergste. Dit blyk goed te wees vir beide Span A en Span D solank ons ​​mekaar kan ignoreer.

In 'n monorepository is die derde regtig nie 'n opsie nie. Jy moet die situasie op een van twee maniere hanteer. Jy moet die bokoste van twee vrylatingtakke sien. Leer om jouself te beskerm teen opdaterings wat terugwaartse versoenbaarheid verbreek. Maar die belangrikste: jy kan nie 'n moeilike gesprek vermy nie.

In my ervaring, wanneer spanne groot word, is dit nie meer moontlik om die hele stelsel in gedagte te hou nie, en dit is die belangrikste deel. U moet die sigbaarheid van meningsverskille in die stelsel verbeter. Jy moet aktief werk om spanne te kry om hul oë van hul komponente af te haal en na die werk van ander spanne en verbruikers te kyk.

Ja, jy kan gereedskap skep wat sal probeer om die probleem van polyrepositories op te los. Maar my ervaring om deurlopende aflewering en outomatisering in groot ondernemings te leer, sê vir my dit: die standaardgedrag sonder die gebruik van bykomende gereedskap is die gedrag wat jy verwag om te sien. Die standaardgedrag van 'n polyrepository is isolasie, dit is die hele punt. Die standaardgedrag van 'n monorepository is gedeelde verantwoordelikheid en deursigtigheid, dit is die hele punt. In albei gevalle gaan ek 'n instrument skep wat skerp hoeke glad maak. As 'n leier sal ek elke keer 'n monorepository kies, want die gereedskap is veronderstel om die kultuur te versterk wat ek wil hê, en kultuur kom uit klein besluite en die daaglikse werk van die span.

Slegs geregistreerde gebruikers kan aan die opname deelneem. Meld aan, asseblief.

Wie is die groot fanatici? Ondersteuners:

• Monorepositories

• Rust

• Verkeerde peiling / albei

33 gebruikers het gestem. 13 gebruikers het buite stemming gebly.

Bron: will.com