A cikk fordítása a kurzus hallgatói számára készült az új fordítást osztjuk meg veletek. Induljunk. az OTUS oktatási projektben.

Monorepozitóriumot kell választania, mert az a viselkedés, amelyet a csapataidban elősegít - az átláthatóság és a kollektív felelősség, különösen a csapatok növekedésekor. Egyébként is befektetésre lesz szükséged az eszközökbe, de mindig jobb, ha az alapértelmezett viselkedés az, amelyet a csapataidban látni szeretnél.

Miért beszélünk erről?

Matt Klein írt egy cikket „Monorepos: Kérlek, ne!” (fordító megjegyzése: fordítás a Habr-on „Monorepozitóriumok: kérlek, ne tedd”). Szeretem Mattet, szerintem nagyon okos, és el kell olvasnod a véleményét. Eredetileg egy Twitter-en készített felmérést tett közzé:

Fordítás:
Ezen az újévi napon arról fogok vitatkozni, hogy mennyire abszurdak a monorepo-k. 2019 észrevétlenül kezdődött. Ennek szellemében ajánlok egy felmérést. Kik a legnagyobb fanatikusok? Támogatók:
— Monorepo
— Rust
— Hibás felmérés / mindkettő

A válaszom ez volt: „Én valójában mindkét ember vagyok”. Ahelyett, hogy arról beszélnénk, hogy a Rust milyen drog, nézzük meg, miért gondolom, hogy téved a monorepo-kkal kapcsolatban. Egy kis információ rólam. A Chef Software technikai igazgatója vagyok. Körülbelül 100 mérnökünk van, egy körülbelül 11-12 éves kódbázissal és 4 fő termékkel. Ennek a kódnak egy része polirepo-ban van (ez az én kiindulási pozícióm), míg egy része monorepo-ban (ez a jelenlegi pozícióm).

Mielőtt elkezdeném: minden érvet, amit itt felhozok, mindkét típusú tárolóra alkalmazni fogok. Véleményem szerint nincs technikai ok arra, hogy miért kellene választania bármelyik tárolótípus mellett. Bármelyik megközelítést működőképessé teheti. Szívesen beszélek erről, de nem érdekelnek a mesterséges technikai okok, amelyek az egyikről a másikra való fölényről szólnak.

Egyetértek Matt véleményének első részével:

Mert nagy léptékben a monorepo ugyanazokat a problémákat fogja kezelni, mint a polirepo, de arra fog ösztönözni, hogy a kódod erősebb összefonódásával dolgozz, és hihetetlen erőfeszítéseket igényel a verziókezelő rendszered skálázhatóságának növelésében.

Ugyanazokkal a problémákkal kell szembenéznie, függetlenül attól, hogy monorepo-t vagy polirepo-t választ. Hogyan kezelik a kiadásokat? Mi a megközelítésük a frissítésekhez? Visszafelé kompatibilitás? Kereszt-függőségek a projektek között? Milyen architekturális stílusok elfogadhatóak? Hogyan irányítja az építési és tesztelési infrastruktúráját? A lista végtelen. És mindezeket meg kell oldania, ahogy növekszik. Nincs ingyen sajt.

Gondolom, Matt érve hasonló a sok mérnök (és menedzser) nézeteihez, akiket tisztelek. Ez egy mérnöki szempontból jön, aki egy komponensen dolgozik, vagy egy csapat, amely egy komponensen dolgozik. Olyan dolgokat hallanak, mint:

A kódalap terjedelmes – nem szükségem minden erre a sok felesleges dologra.
Nehéz ezt tesztelni, mert ellenőriznem kell az összes felesleges dolgot, amire nincs szükségem.
Nehéz külső függőségekkel dolgozni.
Szükségem van a saját verziókezelő virtuális rendszereimre.

Határozottan mindezek az érvek megalapozottak. Ez mindkét esetben így van — a polirepónál van felesleges dolgom, azon kívül, ami az építkezéshez szükséges... Lehet, hogy más felesleges dolgokra is szükségem van. Ezért "csak" olyan eszközöket készítek, amelyek checkout-olják az egész projektet. Vagy létrehozok egy hamis monorepót almódokkal. Egész nap járkálhatunk e körül. De azt gondolom, hogy Matt érve figyelmen kívül hagyja a fő okot, amit én meglehetősen erősen elforgattam a monorepo javára:

Fokozza a kommunikációt és bemutatja a problémákat.

Amikor megosztjuk a repo-kat, de facto koordinációs és átláthatósági problémát teremtünk. Ez megfelel annak, ahogyan a csapatokra gondolunk (főleg ahogyan az egyes tagok gondolkodnak róluk): felelősséget vállalunk egy adott komponensért. Relatív elszigeteltségben dolgozunk. A határok rögzítve vannak a csapatomra és a komponens(- ek)re, amin dolgozunk.

Ahogy az architektúra egyre bonyolultabbá válik, egy csapat már nem tudja egyedül irányítani azt. Nagyon kevés mérnök tudja a teljes rendszert a fejében tartani. Tegyük fel, hogy az A közös komponenst kezeljük, amelyet a B, C és D csapatok használnak. Az A csapat refaktoriálja, javítja az API-t, valamint megváltoztatja a belső megvalósítást. Ennek eredményeként a változások hátramenetileg nem kompatibilisek. Milyen tanácsot adna?

Keresse meg az összes helyet, ahol a régi API-t használják.
Vannak olyan helyek, ahol az új API nem használható?
Meg tudja javítani és tesztelni a többi komponenst, hogy biztos legyen benne, hogy nem fognak hibásan működni?
Ezek a csapatok most azonnal ellenőrizhetik a változtatásait?

Vegye figyelembe, hogy ezek a kérdések nem függnek a tároló típusától. Meg kell találnia a B, C és D csapatokat. Beszélnie kell velük, kideríteni az időbeosztásukat, megérteni a prioritásaikat. Legalább reméljük, hogy ezt megteszi.

Valójában senki sem szeretne ezzel foglalkozni. Sokkal kevésbé izgalmas, mint csak javítani a fránya API-t. Ez egész emberi és bonyolult. A polirepozitóriumban egyszerűen végezhet módosításokat, benyújthatja felülvizsgálatra azoknak, akik ezzel a komponenssel foglalkoznak (valószínűleg nem a B, C vagy D), és tovább léphet. A B, C és D csapatok egy ideig maradhatnak a jelenlegi verziójukon. Frissíteni fognak, amikor rájönnek az Ön zsenialitására!

A monorepozitóriumban a felelősség alapértelmezés szerint áthelyeződik. Az A csapat megváltoztatja a saját komponensét, és ha nem figyel, azonnal tönkreteszi a B, C és D-t. Ez azt eredményezi, hogy a B, C és D csapatok megjelennek az A ajtajában, azon tűnődve, miért töltötte le az A csapat a buildet. Ez megtanítja az A-t, hogy nem hagyhatja figyelmen kívül a fenti listámat. Beszélniük kell arról, hogy mit fognak tenni. El tudnak mozdulni a B, C és D? Mi van, ha a B és C tudnak, de a D szorosan kapcsolódik a régi algoritmus viselkedésének mellékhatásához?

Ezután beszélnünk kell arról, hogy hogyan jutunk ki ebből a helyzetből:

Támogat több belső API-t, míg a régi algoritmus elavultnak lesz nyilvánítva, amíg a D le nem tudja állítani a használatát.
Támogat több verziót a kiadásokban, egy régi interfésszel, egy újjal.
A változások A kiadásának késleltetése addig, amíg egyszerre a B, C és D csapatok el nem tudják fogadni.

Tegyük fel, hogy választottunk 1-et, néhány API-t. Ebben az esetben két darab kódunk van. A régi és az új. Elég kényelmes bizonyos helyzetekben. Visszatesszük a régi kódot, elavultnak (deprecated) jelöljük, és egyeztetjük a D csapattal a törlés ütemezését. Lényegében azonos a poly- és a monorepo esetében.

Több verzió kiadásához szükségünk van egy ágra. Most két komponensünk van — A1 és A2. A B és C csapatok az A2-t használják, míg D az A1-et. Szükségünk van arra, hogy minden komponens készen álljon a kiadásra, mert mielőtt D továbbléphet, biztonsági frissítésekre és más hibajavításokra lehet szükség. A polirepo esetében ezt elrejthetjük egy hosszú életű ágon, ami jól működik. A monorepóban kényszerítve létrehozzuk a kódot egy új modulban. A D csapatnak továbbra is módosítania kell a „régi” komponenst. Mindenki láthatja az árát, amit itt fizetünk — mostantól kétszer annyi kódunk van, és minden hibajavítást, amelyet az A1-re és A2-re alkalmazunk, mindkettőre alkalmazni kell. Az ágak használatával a polireponálás során ez a cherry-pick mögé rejtve van. Az árát alacsonyabbnak tartjuk, mert ott nincs duplikáció. Gyakorlatilag az ár ugyanaz: két, főként azonos kódalapot fogsz létrehozni, kiadni és karbantartani, amíg nem tudsz eltávolítani egyet közülük. A különbség annyi, hogy a monorepo esetében ez a fájdalom közvetlen és szem előtt van. Ez még rosszabb, és ez jó.

Végre eljutottunk a harmadik ponthoz. A kiadás késleltetése. Lehet, hogy A módosításai javítani fogják A csapat életét. Fontos, de nem sürgős. Meg tudjuk várni? A monorepóban arra ösztönözzük magunkat, hogy rögzítsük az artefaktumot. Természetesen beszélünk erről D csapattal. Csak maradjatok a régi verzión, amíg utol nem értek! Ez a „mókuskerék” játékra ösztönöz. A csapat A folyamatosan dolgozik a kompenensén, figyelmen kívül hagyva, hogy a csapat D egyre elavultabb verziót használ (ez D csapat problémája, hülyék). Eközben D csapat kifejezetten rossz szemmel nézi A csapat hanyag hozzáállását a kód stabilitásához, ha egyáltalán róla beszélnek. Hónapok telnek el. Végül D csapat úgy dönt, hogy megnézi a frissítési lehetőséget, de A-ban csak még több változás történt. A csapat A alig emlékszik, mikor és hogyan rombolták le D-t. A frissítés fájdalmasabb és több időt vesz igénybe. Ami tovább küldi lefelé a prioritáslistán. Egészen addig a napig, amíg nem merül fel egy biztonsági probléma A-ban, ami arra kényszerít minket, hogy ágazatot készítsünk. A csapat A-nak vissza kell mennie az időben, megkeresni azt a pillanatot, amikor D stabil volt, javítani a problémát, és előkészíteni a kiadásra. Ez de facto választás, amit az emberek hoznak, és ez határozottan a legrosszabb. Úgy tűnik, hogy ez jó mind A, mind D csapatának, amíg figyelmen kívül tudjuk hagyni egymást.

A monorepóban a harmadik - tényleg nem opció. Két módon kell megbirkóznod a helyzettel. Látni kell a két kiadási ág költségeit. Meg kell tanulnod megvédeni magad az inkompatibilitást törő frissítések ellen. De a legfontosabb: nem tudod elkerülni a nehéz beszélgetéseket.

Tapasztalatom szerint, amikor a csapatok nagyokká válnak, már nem lehetséges az egész rendszer fejben tartása, ami a legfontosabb rész. Fejlesztened kell a különbségek láthatóságát a rendszerben. Aktívan dolgoznod kell azon, hogy ösztönözd a csapatokat, hogy ne csak a saját komponensükre figyeljenek, hanem a többi csapat és a felhasználók munkájára is.

Igen, létrehozhat olyan eszközöket, amelyek próbálnak megoldani a polirepozitóriumok problémáját. De a folyamatos szállítás (continuous delivery) és a nagyvállalati automatizálás terén szerzett tapasztalataim azt mondják, hogy az alapértelmezett viselkedés, ha nem használnak extra eszközöket, az az, amit elvárnak az emberek. A polirepozitórium alapértelmezett viselkedése a szeparáció, ez a lényeg. A monorepozitórium alapértelmezett viselkedése a közös felelősség és átláthatóság, ez a lényeg. Mindkét esetben olyan eszközt fogok létrehozni, amely segít kisimítani a nehézségeket. Vezetőként mindig a monorepozitórium mellett döntök, mert az eszközöknek erősíteniük kell azt a kultúrát, amelyet szeretnék, és a kultúra a kis döntésekből és a csapat napi munkájából származik.

Csak a regisztrált felhasználók vehetnek részt a szavazáson. Kérem, jelentkezzen be., kérem.