Traducció de l'article preparat per als estudiants del curs "Pràctiques i eines de DevOps" en el projecte educatiu OTUS.

Hauríeu de triar un monorepositori perquè el comportament que promou als vostres equips és la transparència i la responsabilitat compartida, sobretot a mesura que els equips creixen. De qualsevol manera, haureu d'invertir en eines, però sempre és millor si el comportament predeterminat és el que voleu a les vostres ordres.

Per què estem parlant d'això?

Matt Klein va escriure l'article "Monorepos: si us plau, no!"  (nota del traductor: traducció a Habré "Monorepositoris: si us plau, no"). M'agrada Matt, crec que és molt intel·ligent i hauries de llegir el seu punt de vista. Inicialment va publicar l'enquesta a Twitter:

Traducció:
Aquest dia de Cap d'Any, discutiré com de ridículs són els monorepositoris. El 2019 va començar tranquil. Amb aquest esperit, us proposo una enquesta. Qui són els grans fanàtics? Partidaris:
- Monorepo
- Rovell
- Enquesta incorrecta / ambdues

La meva resposta va ser: "Literalment sóc les dues persones". En lloc de parlar de com Rust és una droga, mirem per què crec que s'equivoca amb els monorepositoris. Una mica sobre tu mateix. Sóc el CTO de Chef Software. Tenim uns 100 enginyers, una base de codi que es remunta a uns 11-12 anys i 4 productes principals. Una part d'aquest codi es troba en un polirepositori (la meva posició inicial), una part es troba en un monorepositori (la meva posició actual).

Abans de començar: tots els arguments que faig aquí s'aplicaran als dos tipus de repositoris. Al meu entendre, no hi ha cap raó tècnica per la qual escolliu un tipus de repositori per sobre d'un altre. Podeu fer que qualsevol enfocament funcioni. M'alegra parlar-ne, però no m'interessen les raons tècniques artificials per les quals una és superior a l'altra.

Estic d'acord amb la primera part del punt de Matt:

Perquè a escala, un monorepositori resoldrà els mateixos problemes que soluciona un polirepositori, però al mateix temps us obligarà a acoblar el vostre codi i requerirà esforços increïbles per augmentar l'escalabilitat del vostre sistema de control de versions.

Haureu de resoldre els mateixos problemes independentment de si trieu un monorepositori o un polirepositori. Com allibereu els llançaments? Quin és el vostre enfocament a les actualitzacions? Compatibilitat enrere? Dependències creuades del projecte? Quins estils arquitectònics són acceptables? Com gestioneu la vostra infraestructura de construcció i prova? La llista és interminable. I els aniràs resolent tots a mesura que creixis. No hi ha formatge gratuït.

Crec que l'argument de Matt és similar als punts de vista compartits per molts enginyers (i directius) que respecte. Això passa des de la perspectiva de l'enginyer que treballa en el component o l'equip que treballa en el component. Escolteu coses com:

• La base de codi és voluminosa: no necessito tota aquesta brossa.
• És més difícil de provar perquè he de provar tota aquesta brossa que no necessito.
• És més difícil treballar amb dependències externes.
• Necessito els meus propis sistemes de control de versions virtuals.

Per descomptat, tots aquests punts estan justificats. Això passa en ambdós casos: al polirepositori tinc la meva pròpia brossa, a més de la necessària per a la compilació... És possible que també necessiti altres brossa. Així que "simplement" creo eines que comproven tot el projecte. O creo un fals monorepositori amb submòduls. Podríem caminar per això tot el dia. Però crec que l'argument de Matt passa a faltar la raó principal, que vaig inclinar força a favor del monorepositori:

Provoca comunicació i mostra problemes

Quan separem els dipòsits, creem un problema de facto de coordinació i transparència. Això correspon a la manera com pensem sobre els equips (especialment la manera com els membres individuals pensen sobre ells): som responsables d'un determinat component. Treballem de manera relativament aïllada. Els límits estan fixats en el meu equip i en els components en els quals estem treballant.

A mesura que l'arquitectura es fa més complexa, un equip ja no pot gestionar-la sol. Molt pocs enginyers tenen tot el sistema al cap. Suposem que gestioneu un component A compartit que utilitzen els equips B, C i D. L'equip A està refactoritzant, millorant l'API i també canviant la implementació interna. Com a resultat, els canvis no són retrocompatibles. Quins consells tens?

• Cerca tots els llocs on s'utilitza l'API antiga.
• Hi ha llocs on no es pot utilitzar la nova API?
• Podeu arreglar i provar altres components per assegurar-vos que no es trenquin?
• Aquests equips poden provar els vostres canvis ara mateix?

Tingueu en compte que aquestes preguntes són independents del tipus de repositori. Haureu de trobar els equips B, C i D. Haureu de parlar amb ells, conèixer l'horari, entendre les seves prioritats. Almenys esperem que ho facis.

Ningú realment vol fer això. Això és molt menys divertit que arreglar la maleïda API. Tot és humà i desordenat. En un polirepositori, simplement podeu fer canvis, donar-los a les persones que treballen en aquest component (probablement no B, C o D) perquè la revisin i seguir endavant. Els equips B, C i D només poden quedar-se amb la seva versió actual de moment. Es renovaran quan s'adonin del teu geni!

En un monorepositori, la responsabilitat es desplaça per defecte. L'equip A canvia el seu component i, si no té cura, immediatament trenca B, C i D. Això fa que B, C i D apareguin a la porta d'A, preguntant-se per què l'equip A va trencar el muntatge. Això ensenya a A que no poden saltar la meva llista anterior. Han de parlar del que faran. Es poden moure B, C i D? Què passa si B i C poden, però D estigués estretament relacionat amb un efecte secundari del comportament de l'antic algorisme?

Aleshores hem de parlar de com sortirem d'aquesta situació:

1. Admet diverses API internes i marcarà l'antic algorisme com a obsolet fins que D pugui deixar d'utilitzar-lo.
2. Suport per a diverses versions de llançament, una amb la interfície antiga i una altra amb la nova.
3. Retarda la publicació dels canvis d'A fins que B, C i D puguin acceptar-los simultàniament.

Suposem que hem seleccionat 1, diverses API. En aquest cas tenim dos fragments de codi. Vell i nou. Molt convenient en algunes situacions. Tornem a comprovar el codi antic, el marquem com a obsolet i acordem un calendari d'eliminació amb l'equip D Essencialment idèntic per als dipòsits poli i mono.

Per llançar diverses versions, necessitem una branca. Ara tenim dos components: A1 i A2. Els equips B i C utilitzen A2 i D utilitza A1. Necessitem que tots els components estiguin preparats per al seu llançament perquè poden ser necessàries actualitzacions de seguretat i altres correccions d'errors abans que D pugui avançar. En un polirepositori, ho podem amagar en una branca de llarga vida que se senti bé. En un monorepositori, obliguem a crear el codi en un mòdul nou. L'equip D encara haurà de fer canvis al component "antic". Tothom pot veure el cost que estem pagant aquí: ara tenim el doble de codi i qualsevol correcció d'errors que s'apliqui a A1 i A2 s'ha d'aplicar a tots dos. Amb l'enfocament de ramificació en un polirepositori, això s'amaga darrere de la selecció de cireres. Considerem que el cost és més baix perquè no hi ha duplicació. Des d'un punt de vista pràctic, el cost és el mateix: creareu, alliberareu i mantindreu dues bases de codi gairebé idèntiques fins que en pugueu eliminar una. La diferència és que amb un monorepositori aquest dolor és directe i visible. Això és encara pitjor, i això és bo.

Finalment, hem arribat al tercer punt. Retard de llançament. És possible que els canvis fets per A millorin la vida de l'equip A. Important, però no urgent. Només podem retardar? En un polirepositori, pressionem això per fixar l'artefacte. Per descomptat, ho diem a l'equip D. Només cal que mantingueu la versió antiga fins que us poseu al dia! Això et prepara per jugar al covard. L'equip A continua treballant en el seu component, ignorant el fet que l'equip D està utilitzant una versió cada cop més obsoleta (aquest és el problema de l'equip D, són estúpids). Mentrestant, l'equip D parla malament de l'actitud descuidada de l'equip A cap a l'estabilitat del codi, si en parlen. Passen els mesos. Finalment, l'equip D decideix mirar la possibilitat d'una actualització, però A només té més canvis. L'equip A amb prou feines recorda quan o com van trencar D. L'actualització és més dolorosa i trigarà més temps. La qual cosa l'envia més avall a la pila de prioritats. Fins el dia que tenim un problema de seguretat a A que ens obliga a fer branca. L'equip A ha de retrocedir en el temps, trobar un punt en què D era estable, solucionar el problema allà i preparar-lo per al llançament. Aquesta és l'elecció de facto que fa la gent, i és, amb diferència, la pitjor. Sembla ser bo tant per a l'equip A com per a l'equip D sempre que ens puguem ignorar.

En un monorepositori, el tercer no és realment una opció. Estàs obligat a fer front a la situació de dues maneres. Heu de veure els costos de tenir dues branques de llançament. Apreneu a protegir-vos de les actualitzacions que trenquin la compatibilitat enrere. Però el més important: no pots evitar tenir una conversa difícil.

Segons la meva experiència, quan els equips es fan grans, ja no és possible tenir en compte tot el sistema, i aquesta és la part més important. Heu de millorar la visibilitat de la discordia al sistema. Heu de treballar activament per aconseguir que els equips destinin la vista dels seus components i miren el treball d'altres equips i consumidors.

Sí, podeu crear eines que intentin resoldre el problema del polirepositori. Però la meva experiència ensenyant el lliurament continu i l'automatització a les grans empreses em diu això: el comportament predeterminat sense l'ús d'eines addicionals és el comportament que espereu veure. El comportament predeterminat d'un polirepositori és l'aïllament, aquest és tot el punt. El comportament per defecte d'un monorepositori és la responsabilitat compartida i la transparència, aquest és el punt. En ambdós casos, crearé una eina que suavitzi les vores aspres. Com a líder, triaré un monorepositori cada vegada perquè les eines necessiten reforçar la cultura que vull, i la cultura prové de petites decisions i del treball diari de l'equip.

Només els usuaris registrats poden participar en l'enquesta. Inicia sessiósi us plau.

Quins són els grans fanàtics? Partidaris:

• Monorepo

• Rovell

• Enquesta incorrecta / ambdues

Han votat 33 usuaris. 13 usuaris es van abstenir.

Font: www.habr.com