Aunque tienen naturalezas distintas, ¿cómo prefieren integrar (o no integrar) varios proyectos relacionados?
Por ejemplo, si para un mismo servicio existen front-end, back-end (API), serverless, batch, pipeline, etc.
-
Mono-repo
Si el servicio es el mismo, ¡entonces el repositorio es uno solo! Cada proyecto se organiza en una estructura de paquetes/carpetas
-> Pero, ¿cómo manejan los commits...? CI/CD o hooks como pre-commit se volverían más complejos... -
Git Submodules
Si la naturaleza es distinta, ¡al menos el historial de git debería administrarse por separado! Aun así, intentando agruparlo lo más posible en uno solo...
-> La curva de aprendizaje de cosas como submodule sync... los merges también se complican... ¿los demás desarrolladores podrán seguirlo? -
Repos separados
¡Simple! Si es otro proyecto, ¡otro repo!
-> Si quiero ver el servicio A, ¿qué repo tengo que revisar? Ah, este, aquel... ¿y qué más había...?
No creo que haya una respuesta correcta, pero me da curiosidad saber cuál prefieren y por qué.
16 comentarios
Yo prefiero repos separados...
Cuando me surge la pregunta: “si quiero ver el historial del API relacionado con esta funcionalidad, ¿qué debería revisar?”, me resulta más cómodo hacer que un repositorio corresponda a una sola funcionalidad.
Yo uso monorepo en la mayoría de los casos, pero hay 2 casos en los que sí uso submódulos.
Cuando contrato a un publisher externo.
Uso submódulos cuando no quiero revelar al publisher externo cosas que no sean la información necesaria para el publishing.
Cuando hay que personalizar una solución externa.
Sobre todo cuando se trata de una solución que ofrece funcionalidad de plugins, uso submódulos.
Registro esa solución externa como submódulo y trabajo metiendo mis plugins dentro de la ruta de plugins mediante symlinks o algo similar. Mis plugins los gestiono con control de versiones por separado, y la ventaja es que la solución externa puede mantener intacto su propio control de versiones.
Parece que todos han tenido malas experiencias usando submodules... Ojalá hubiera alguna herramienta que pudiera mejorarlo.
Si tienes confianza de hacer solo commits de merge, monorepo,
si vas a hacer rebase seguido, multirepo,
¿submódulos? Mejor usa los enlaces de directorio que ofrece el propio SO…
Antes simplemente usaba repositorios independientes para cada cosa, pero últimamente cambié por completo al método de usar submódulos.
Antes no entendía bien git, así que no podía aprovechar correctamente los submódulos, pero ahora pienso que usarlos es una mejor opción.
Eso sí, al usar submódulos tienes que hacer un commit en ese submódulo y luego volver a hacer otro commit en el repo padre, y como resultado se genera una diferencia entre ambos momentos, lo que parece traer el problema de que baja la consistencia del repositorio.
https://monorepo.tools/
Si no han visto ese sitio, creo que vale la pena echarle un vistazo.
Por experiencia personal, no recomiendo los submódulos.
Si quieren compartir código de otro repositorio usando submódulos, creo que sería mejor publicarlo como paquete.
En nuestra empresa, como hay pocos integrantes por proyecto y los lenguajes y stacks tecnológicos de frontend y backend están separados, casi no hubo contribuciones cruzadas entre roles. Como pasa con todos los sistemas de TI, al final parece que todo termina siguiendo la estructura de la organización.
Oh... entonces es un enfoque para ajustar la visibilidad del código ajeno según si la interfaz la adapta la persona o la herramienta.
Como no tengo experiencia con mono-repos, tengo una duda. Cuando se trabaja con un mono-repo, ¿los módulos comunes a varios proyectos o servicios (p. ej., un sistema de diseño) también van dentro de ese mismo mono-repo? ¿O esos inevitablemente se separan en un repo aparte y se referencian desde ahí?
Parece que para acceder a módulos compartidos usábamos algo como yarn workspace para hacerlo en forma de symlink.
Yo, tanto en la empresa como en proyectos personales, gestiono frontend, backend, batch, etc., sin separarlos, todo en un solo git.
A veces, en vez de mantener compatibilidad hacia atrás, es más cómodo modificar ambos juntos. En ambos casos los equipos son pequeños, así que diría que no había mucho que ganar separándolos por separado... El esfuerzo de configurar GitHub Actions para que solo corriera en las partes modificadas fue algo manejable. Sobre todo, más que dividir entre backend y frontend, diría que lo bueno es que cada lado pueda contribuir al otro. (Por ejemplo, mientras trabajo en el frontend, si hace falta algo en el backend lo agrego yo mismo, o también corrijo errores directamente, etc.)
Mmm, parece que claramente prefieren el monorepo cuando la escala es pequeña o los roles no están estrictamente definidos. ¿Tampoco les molesta mucho que se mezcle el historial de Git? (¿Porque al final de cuentas igual todos ven todo el código?)
Lo interesante es que en mi proyecto paralelo también pasa algo así. Hasta ahora he trabajado con unas 12 personas, y cada una se encarga de todo de punta a punta, desde el frontend hasta el backend. Supongo que también es algo parecido a un vertical slice.
No suelo verlo como algo mezclado. A menudo también hay casos en los que se modifican tanto el frontend como el backend en un solo PR. En nuestro caso, la idea es que todos somos 4 personas full stack, así que, sin importar si es backend o frontend, revisamos el trabajo de los demás y también necesitamos conocer los cambios.
Si el módulo no es muy grande, monorepo.
Si el módulo es grande, submódulo.
O si al distribuirlo como open source quieres permitir contribuciones solo al submódulo y configurar el repositorio principal para administrarlo por separado,
parece que lo mejor es dividirlo como submódulo.
Pero cuando metes submódulos, al hacerlo open source sí da la impresión de que para otros usuarios se vuelve un poco más complejo escribir documentación sobre pruebas o build con fines de contribución.
Así que, personalmente, salvo que la forma de contribuir a ambos sea distinta, creo que lo manejaría como monorepo,
o lo separaría en distintos GitHub y administraría cada uno distribuyéndolo como paquete o como imagen de Docker.
No había pensado en lo relacionado con el código abierto, ¡gracias por tu opinión!