Tradución do artigo elaborado para os alumnos do curso "Prácticas e ferramentas de DevOps" no proxecto educativo OTUS.

Deberías escoller un monorepositorio porque o comportamento que promove nos teus equipos é a transparencia e a responsabilidade compartida, especialmente a medida que os equipos medran. De calquera xeito, terás que investir en ferramentas, pero sempre é mellor se o comportamento predeterminado é o que queres nos teus comandos.

Por que falamos disto?

Matt Klein escribiu o artigo "Monorepos: Por favor, non!"  (nota do tradutor: tradución sobre Habré "Monorrepositorios: por favor non"). Gústame Matt, creo que é moi intelixente e deberías ler o seu punto de vista. El publicou orixinalmente a enquisa en Twitter:

Tradución:
Este día de Ano Novo, vou discutir sobre o ridículo que son os monorepositorios. O 2019 comezou tranquilo. Neste sentido, ofrézoche unha enquisa. Quen son os grandes fanáticos? Apoiantes:
- Monorepo
- Ferrugem
- Enquisa incorrecta / ambas

A miña resposta foi: "Eu son literalmente esas dúas persoas". En lugar de falar de como Rust é unha droga, vexamos por que creo que se equivoca sobre os monorepositorios. Un pouco sobre ti. Son o CTO de Chef Software. Temos uns 100 enxeñeiros, unha base de código que se remonta a uns 11-12 anos e 4 produtos principais. Parte deste código atópase nun polirepositorio (a miña posición inicial), outro nun monorepositorio (a miña posición actual).

Antes de comezar: todos os argumentos que fago aquí aplicaranse a ambos os tipos de repositorios. Na miña opinión, non hai ningunha razón técnica para escoller un tipo de repositorio sobre outro. Podes facer que calquera enfoque funcione. Estou encantado de falar diso, pero non me interesan as razóns técnicas artificiais polas que unha é superior a outra.

Estou de acordo coa primeira parte do punto de Matt:

Porque a escala, un monorepositorio resolverá os mesmos problemas que soluciona un polirepositorio, pero ao mesmo tempo obrigándoche a acoplar estreitamente o teu código e requirirá esforzos incribles para aumentar a escalabilidade do teu sistema de control de versións.

Terás que resolver os mesmos problemas independentemente de se elixes un monorepositorio ou un polirepositorio. Como lanzas lanzamentos? Cal é o teu enfoque das actualizacións? Compatibilidade con versións anteriores? Dependencias cruzadas do proxecto? Que estilos arquitectónicos son aceptables? Como xestionas a túa infraestrutura de construción e proba? A lista é infinita. E resolverás todas a medida que medres. Non hai queixo gratis.

Creo que o argumento de Matt é semellante aos puntos de vista compartidos por moitos enxeñeiros (e xestores) que respecto. Isto ocorre dende a perspectiva do enxeñeiro que traballa no compoñente ou do equipo que traballa no compoñente. Escoitas cousas como:

• O código base é voluminoso: non necesito todo este lixo.
• É máis difícil probar porque teño que probar todo este lixo que non necesito.
• É máis difícil traballar con dependencias externas.
• Necesito os meus propios sistemas virtuais de control de versións.

Por suposto, todos estes puntos están xustificados. Isto ocorre en ambos os casos: no polirepositorio teño o meu propio lixo, ademais do necesario para a compilación... É posible que tamén necesite outro lixo. Así que "simplemente" creo ferramentas que verifican todo o proxecto. Ou creo un monorepositorio falso con submódulos. Poderiamos andar por isto todo o día. Pero creo que o argumento de Matt perde a razón principal, que dei unha volta bastante a favor do monorepositorio:

Provoca comunicación e mostra problemas

Cando separamos os repositorios, creamos un problema de facto de coordinación e transparencia. Isto correspóndese coa forma en que pensamos sobre os equipos (especialmente a forma en que os membros individuais pensan sobre eles): somos responsables dun determinado compoñente. Traballamos nun relativo illamento. Os límites están fixados no meu equipo e no(s) compoñente(s) nos que estamos a traballar.

A medida que a arquitectura se fai máis complexa, un equipo xa non pode xestionala só. Moi poucos enxeñeiros teñen todo o sistema na cabeza. Digamos que xestionas un compoñente compartido A que usan os equipos B, C e D. O equipo A está a refactorizar, mellorar a API e tamén cambiar a implementación interna. Como resultado, os cambios non son compatibles cara atrás. Que consello tes?

• Busca todos os lugares onde se utiliza a API antiga.
• Hai lugares onde non se pode usar a nova API?
• Podes arranxar e probar outros compoñentes para asegurarte de que non se rompan?
• Estes equipos poden probar os teus cambios agora mesmo?

Teña en conta que estas preguntas son independentes do tipo de repositorio. Necesitarás atopar os equipos B, C e D. Haberá que falar con eles, coñecer a hora, comprender as súas prioridades. Polo menos esperamos que o fagas.

Ninguén realmente quere facer isto. Isto é moito menos divertido que só arranxar a maldita API. É todo humano e desordenado. Nun polirepositorio, pode simplemente facer cambios, darllo ás persoas que traballan nese compoñente (probablemente non B, C ou D) para a súa revisión e seguir adiante. Os equipos B, C e D poden quedarse coa súa versión actual polo momento. Renovaranse cando se dean conta do teu xenio!

Nun monorepositorio, a responsabilidade cámbiase por defecto. O equipo A cambia o seu compoñente e, se non ten coidado, rompe inmediatamente B, C e D. Isto leva a que B, C e D aparezan na porta de A, preguntándose por que o equipo A rompeu a montaxe. Isto ensínalle a A que non poden saltar a miña lista anterior. Deben falar do que van facer. Pódense mover B, C e D? E se B e C poden, pero D estivese moi relacionado cun efecto secundario do comportamento do antigo algoritmo?

Despois temos que falar de como sairemos desta situación:

1. Compatibilidade con varias API internas e marcará o algoritmo antigo como obsoleto ata que D poida deixar de usalo.
2. Soporte para varias versións, unha coa interface antiga e outra coa nova.
3. Retrasa a publicación dos cambios de A ata que B, C e D poidan aceptalo simultáneamente.

Digamos que seleccionamos 1, varias API. Neste caso temos dúas pezas de código. Vello e novo. Moi cómodo nalgunhas situacións. Volvemos a verificar o código antigo, marcamos como obsoleto e acordamos un calendario de eliminación co equipo D. Esencialmente idéntico para os repositorios multi e mono.

Para lanzar varias versións, necesitamos unha rama. Agora temos dous compoñentes: A1 e A2. Os equipos B e C usan A2 e D usa A1. Necesitamos que todos os compoñentes estean listos para o lanzamento porque poden ser necesarias actualizacións de seguranza e outras correccións de erros antes de que D poida avanzar. Nun polirepositorio, podemos ocultar isto nunha rama de longa duración que se sinta ben. Nun monorepositorio, obrigamos a crear o código nun módulo novo. O equipo D aínda terá que facer cambios no compoñente "antigo". Todo o mundo pode ver o custo que estamos pagando aquí: agora temos o dobre de código e calquera corrección de erros que se aplique a A1 e A2 debe aplicarse a ambos. Co enfoque de ramificación nun polirepositorio, isto está oculto detrás da selección de cereixas. Consideramos que o custo é menor porque non hai duplicidades. Desde un punto de vista práctico, o custo é o mesmo: crearás, lanzarás e manterás dúas bases de código en gran parte idénticas ata que poidas eliminar unha delas. A diferenza é que cun monorepositorio esta dor é directa e visible. Isto é aínda peor, e iso é bo.

Finalmente chegamos ao terceiro punto. Atraso de lanzamento. É posible que os cambios realizados por A melloren a vida do Equipo A. Importante, pero non urxente. Podemos só atrasar? Nun polirepositorio, empurramos isto para fixar o artefacto. Por suposto, dicímosllo ao equipo D. Só tes que manter a versión antiga ata que te poñas ao día! Isto prepárache para facer de covarde. O equipo A segue traballando no seu compoñente, ignorando o feito de que o equipo D está a usar unha versión cada vez máis obsoleta (ese é o problema do equipo D, son estúpidos). Mentres tanto, o equipo D fala mal sobre a actitude descoidada do equipo A cara á estabilidade do código, se é que falan diso. Pasan os meses. Finalmente, o equipo D decide analizar a posibilidade de actualizar, pero A só ten máis cambios. O equipo A apenas lembra cando ou como rompeu D. A actualización é máis dolorosa e levará máis tempo. O que o envía máis abaixo na pila de prioridades. Ata o día que temos un problema de seguridade en A que nos obriga a facer un sucursal. O equipo A debe retroceder no tempo, atopar un punto no que D estaba estable, solucionar o problema alí e preparalo para o lanzamento. Esta é a elección de facto que fai a xente, e é de lonxe a peor. Parece ser bo tanto para o equipo A como para o equipo D sempre que poidamos ignorarnos.

Nun monorepositorio, o terceiro realmente non é unha opción. Estás obrigado a xestionar a situación de dúas formas. Debes ver os custos de ter dúas ramas de lanzamento. Aprende a protexerte das actualizacións que rompen a compatibilidade con versións anteriores. Pero o máis importante: non pode evitar ter unha conversación difícil.

Segundo a miña experiencia, cando os equipos se fan grandes, xa non é posible ter presente todo o sistema, e esa é a parte máis importante. Debe mellorar a visibilidade da discordia no sistema. Debes traballar activamente para que os equipos desvíen a vista dos seus compoñentes e miren o traballo doutros equipos e consumidores.

Si, podes crear ferramentas que intenten resolver o problema do polirepositorio. Pero a miña experiencia ensinando a entrega continua e a automatización en grandes empresas dime isto: o comportamento predeterminado sen o uso de ferramentas adicionais é o que esperas ver. O comportamento predeterminado dun polirepositorio é o illamento, ese é o punto. O comportamento predeterminado dun monorepositorio é a responsabilidade compartida e a transparencia, esa é a cuestión. En ambos os casos, vou crear unha ferramenta que suavizará os bordos ásperos. Como líder, escollerei un monorepositorio cada vez porque as ferramentas precisan reforzar a cultura que quero, e a cultura vén de pequenas decisións e do traballo diario do equipo.

Só os usuarios rexistrados poden participar na enquisa. Rexístrate, por favor.

Quen son os maiores fanáticos? Apoiantes:

• Monorepo

• Ferrugem

• Enquisa incorrecta / ambas

Votaron 33 usuarios. 13 usuarios abstivéronse.

Fonte: www.habr.com