A kurzus hallgatói számára készített cikk fordítása "DevOps gyakorlatok és eszközök" az OTUS oktatási projektben.

Egyetlen adattárat kell választania, mert az általa előmozdított viselkedés a csapatokban az átláthatóság és a megosztott felelősség, különösen a csapatok növekedésével. Akárhogy is, be kell fektetnie a szerszámokba, de mindig jobb, ha az alapértelmezett viselkedés a parancsokban kívánt viselkedés.

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

Matt Klein írta a cikket "Monorepos: Kérlek, ne!"  (a fordító megjegyzése: Habré fordítása "Monorepository: kérlek, ne"). Szeretem Mattet, szerintem nagyon okos, és érdemes elolvasni a nézőpontját. Eredetileg a Twitteren tette közzé a szavazást:

Fordítás:
Ezen az újév napján azon fogok vitatkozni, hogy milyen nevetségesek a monorepository-k. 2019 csendesen indult. Ennek szellemében egy felmérést ajánlok Önnek. Kik a nagy fanatikusok? Támogatók:
- Monorepo
- Rozsda
- Helytelen szavazás / mindkettő

A válaszom a következő volt: „Szó szerint mindketten azok az emberek.” Ahelyett, hogy arról beszélnénk, hogy a Rust drog, nézzük meg, miért gondolom, hogy nincs igaza a monorepository-kkal kapcsolatban. Egy kicsit magadról. A Chef Software műszaki igazgatója vagyok. Körülbelül 100 mérnökünk van, körülbelül 11-12 éves kódbázisunk és 4 fő termékünk van. Ennek a kódnak egy része egy polirepozitóriumban van (az én kiinduló pozícióm), néhány pedig egy monorepositoryban (jelenlegi pozícióm).

Mielőtt elkezdeném: minden érv, amelyet itt felhozok, mindkét típusú adattárra vonatkozik. Véleményem szerint nincs technikai oka annak, hogy miért válasszon egy típusú adattárat a másik helyett. Bármilyen megközelítést megvalósíthat. Szívesen beszélek róla, de nem érdekelnek a mesterséges technikai okok, amiért az egyik felülmúlja a másikat.

Egyetértek Matt pontjának első részével:

Mert méretarányosan a monorepository ugyanazokat a problémákat oldja meg, mint a többtároló, de ugyanakkor arra kényszeríti Önt, hogy szorosan összekapcsolja a kódját, és hihetetlen erőfeszítéseket igényel a verzióvezérlő rendszer méretezhetőségének növelése érdekében.

Ugyanazokat a problémákat kell megoldania, függetlenül attól, hogy egy vagy több tárolót választ. Hogyan adsz ki kiadásokat? Hogyan viszonyulsz a frissítésekhez? Visszafelé kompatibilitás? Projektek közötti függőségek? Milyen építészeti stílusok elfogadhatók? Hogyan kezeli az építési és tesztelési infrastruktúrát? A lista végtelen. És mindegyiket megoldja, ahogy nő. Nincs ingyen sajt.

Azt hiszem, Matt érvelése hasonló sok általam tisztelt mérnök (és menedzser) nézetéhez. Ez az alkatrészen dolgozó mérnök vagy az alkatrészen dolgozó csapat szemszögéből következik be. Ilyeneket hallasz:

• A kódbázis terjedelmes – nincs szükségem erre a sok szemétre.
• Nehezebb tesztelni, mert ki kell tesztelnem ezt a sok szemetet, amire nincs szükségem.
• Nehezebb a külső függőségekkel dolgozni.
• Saját virtuális verziókezelő rendszerre van szükségem.

Természetesen mindezek a szempontok jogosak. Ez mindkét esetben megtörténik - a polirepository-ban van saját szemétem, az építkezéshez szükségesen kívül... Lehet, hogy más szemétre is szükségem lesz. Tehát „egyszerűen” olyan eszközöket hozok létre, amelyek ellenőrzik a teljes projektet. Vagy létrehozok egy hamis monorepository-t almodulokkal. Egész nap ezen járhatnánk. De úgy gondolom, hogy Matt érvelése figyelmen kívül hagyja a fő okot, amit meglehetősen erősen a monorepository javára fordítottam:

Kommunikációt provokál és problémákat mutat fel

Amikor szétválasztjuk a tárolókat, de facto koordinációs és átláthatósági problémát okozunk. Ez megfelel annak, ahogyan a csapatokról gondolkodunk (különösen annak, ahogy az egyes tagok gondolkodnak róluk): egy bizonyos összetevőért felelősek vagyunk. Viszonylag elszigetelten dolgozunk. A határok a csapatomon és azon komponens(ek)en vannak rögzítve, amelyeken dolgozunk.

Ahogy az architektúra egyre összetettebbé válik, egy csapat már nem tudja egyedül kezelni. Nagyon kevés mérnöknek van a fejében az egész rendszer. Tegyük fel, hogy Ön egy megosztott A komponenst kezel, amelyet a B, C és D csapat használ. Az A csapat átdolgozza, fejleszti az API-t, és módosítja a belső megvalósítást is. Ennek eredményeként a változtatások nem kompatibilisek visszafelé. Milyen tanácsod van?

• Keresse meg az összes helyet, ahol a régi API-t használják.
• Vannak helyek, ahol az új API nem használható?
• Megjavíthat és tesztelhet más alkatrészeket, hogy megbizonyosodjon arról, hogy nem törnek el?
• Ezek a csapatok most tesztelhetik a változásait?

Kérjük, vegye figyelembe, hogy ezek a kérdések függetlenek a tároló típusától. Meg kell találnod a B, C és D csapatokat. Beszélned kell velük, meg kell találnod az időt, meg kell értened a prioritásaikat. Legalábbis reméljük.

Senki sem akarja ezt igazán csinálni. Ez sokkal kevésbé szórakoztató, mint az átkozott API javítása. Emberi és rendetlen az egész. Egy polirepozitóriumban egyszerűen módosíthat, át kell adnia az adott összetevőn dolgozó embereknek (valószínűleg nem B, C vagy D), és továbbléphet. A B, C és D csapatok egyelőre maradhatnak a jelenlegi verziójuknál. Megújulnak, amikor rájönnek a zsenialitásodra!

Egy monolerakatban a felelősség alapértelmezés szerint át van tolva. Az A-csapat megváltoztatja az alkatrészét, és ha nem vigyáz, azonnal széttöri B, C és D-t. Ez ahhoz vezet, hogy B, C és D megjelenik A ajtajában, és azon töpreng, hogy az A-csapat miért törte fel a szerelvényt. Ez megtanítja A-nak, hogy nem hagyhatják ki a fenti listámat. Beszélniük kell arról, hogy mit fognak tenni. B, C és D mozoghat? Mi van, ha B és C tud, de D szorosan összefügg a régi algoritmus viselkedésének egy mellékhatásával?

Aztán meg kell beszélnünk, hogyan léphetünk ki ebből a helyzetből:

1. Több belső API támogatása, és a régi algoritmust elavultként jelöli meg mindaddig, amíg D le nem tudja hagyni a használatát.
2. Több kiadási verzió támogatása, az egyik a régi felülettel, a másik az újjal.
3. Késleltesse A változtatások kiadását addig, amíg B, C és D egyidejűleg elfogadja azt.

Tegyük fel, hogy kiválasztottunk 1, több API-t. Ebben az esetben két kódrészletünk van. Régi és új. Bizonyos helyzetekben nagyon kényelmes. Visszaellenőrizzük a régi kódot, megjelöljük elavultként, és megállapodunk az eltávolítási ütemezésben a D csapattal. Lényegében megegyezik a poli és mono adattárak 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 csapat az A2-t, a D pedig az A1-et használja. Minden összetevőnek készen kell állnia a kiadásra, mert biztonsági frissítésekre és egyéb hibajavításokra lehet szükség, mielőtt D továbbléphet. Egy polirepozitóriumban ezt elrejthetjük egy hosszú életű ágban, ami jó érzés. A monorepositoryban kényszerítjük a kód létrehozását egy új modulban. A D-csapatnak továbbra is módosítania kell a "régi" komponensen. Mindenki láthatja, hogy mennyit fizetünk itt – most már kétszer annyi kódunk van, és az A1-re és az A2-re vonatkozó hibajavításoknak mindkettőre vonatkozniuk kell. A polirepozitóriumban elágazó megközelítéssel ez a cherry-pick mögé rejtőzik. A költségeket alacsonyabbnak tartjuk, mert nincs párhuzamosság. Gyakorlati szempontból a költség ugyanaz: két nagyrészt azonos kódbázist kell létrehoznia, kiadnia és karbantartania, amíg az egyiket nem tudja törölni. A különbség az, hogy monorepository esetén ez a fájdalom közvetlen és látható. Ez még rosszabb, és ez jó.

Végül elérkeztünk a harmadik ponthoz. Kiadási késleltetés. Lehetséges, hogy az A által végrehajtott változtatások javítják az A-csapat életét. Fontos, de nem sürgős. Csak késlekedhetünk? Egy polirepozitóriumban ezt megnyomjuk a műtermék rögzítéséhez. Természetesen ezt elmondjuk a D csapatnak. Maradjon a régi verziónál, amíg utoléri! Ez arra készteti, hogy játssza a gyávát. Az A-csapat továbbra is dolgozik a komponensén, figyelmen kívül hagyva azt a tényt, hogy a D-csapat egyre elavultabb verziót használ (ez a D-csapat problémája, ők hülyék). Eközben a D-csapat rosszul beszél az A-csapat hanyag hozzáállásáról a kódstabilitáshoz, ha egyáltalán beszélnek róla. Telnek a hónapok. Végül a D-csapat úgy dönt, hogy megvizsgálja a frissítés lehetőségét, de az A-nak csak több módosítása van. Az A-csapat alig emlékszik, mikor és hogyan törték meg D-t. A frissítés fájdalmasabb és tovább tart. Ez lejjebb küldi a prioritási veremben. Egészen addig a napig, amíg A-ban nem lesz biztonsági probléma, amely arra kényszerít bennünket, hogy leágazást hozzunk létre. Az A-csapatnak vissza kell mennie az időben, meg kell találnia egy pontot, amikor D stabil volt, ott meg kell oldani a problémát, és készen kell állnia a kibocsátásra. Ez az emberek de facto döntése, és messze a legrosszabb. Úgy tűnik, ez mind az A-csapatnak, mind a D-csapatnak jó, amíg figyelmen kívül hagyhatjuk egymást.

Egy monorepository-ban a harmadik valóban nem opció. Kénytelen vagy kétféleképpen kezelni a helyzetet. Látnia kell a két kiadási ág költségeit. Tanulja meg megvédeni magát a visszafelé kompatibilitást megsértő frissítésektől. De ami a legfontosabb: nem kerülheti el a nehéz beszélgetést.

Tapasztalatom szerint, amikor a csapatok nagyokká válnak, már nem lehet az egész rendszert szem előtt tartani, és ez a legfontosabb. Javítania kell a viszályok láthatóságát a rendszerben. Aktívan kell dolgoznia annak érdekében, hogy a csapatok eltekintsenek az összetevőiktől, és más csapatok és fogyasztók munkáját nézzék.

Igen, létrehozhat olyan eszközöket, amelyek megpróbálják megoldani a polirepository problémát. De a nagyvállalatoknál a folyamatos szállítás és automatizálás tanításával kapcsolatos tapasztalataim a következőket mondják: az alapértelmezett viselkedés a további eszközök használata nélkül az a viselkedés, amelyet Ön elvár. A polirepository alapértelmezett viselkedése az izoláció, ez a lényeg. A monorepository alapértelmezett viselkedése a megosztott felelősség és az átláthatóság, ez a lényeg. Mindkét esetben olyan eszközt fogok készíteni, amely kisimítja a durva éleket. Vezetőként minden alkalommal monorepository-t fogok választani, mert az eszközöknek meg kell erősíteni a kívánt kultúrát, és a kultúra apró döntésekből és a csapat napi munkájából fakad.

A felmérésben csak regisztrált felhasználók vehetnek részt. Bejelentkezés, kérem.

Kik a legnagyobb fanatikusok? Támogatók:

• Monorepo

• Rozsda

• Helytelen szavazás / mindkettő

33 felhasználó szavazott. 13 felhasználó tartózkodott.

Forrás: will.com