Monorepositorio con Go: organización de código para proyectos escalables

Monorepositorio con Go: organización de código para proyectos escalables

En el desarrollo de software moderno, cada vez surge más la pregunta: ¿cómo organizar el código para que siga siendo manejable, reutilizable y escalable? Una de las soluciones populares es el uso de un monorepositorio (monorepo) — un repositorio único que contiene múltiples proyectos o servicios. En este artículo, analizaremos cómo organizar eficazmente un monorepositorio en el lenguaje Go (Golang), revisaremos las mejores prácticas, la estructura de directorios, el trabajo con módulos y la configuración de CI/CD.

¿Qué es un monorepositorio y por qué es necesario en Go?

Un monorepositorio es un enfoque en el que todo el código de una empresa o de un proyecto grande se almacena en un solo repositorio. Esto puede incluir:

• Varios microservicios
• Bibliotecas y utilidades
• Configuraciones y scripts
• Documentación

Ventajas del monorepositorio para Go:

• Versión única de dependencias — elimina conflictos de versiones entre servicios.
• Simplificación de la refactorización — los cambios en una biblioteca común son visibles de inmediato para todos los consumidores.
• Reutilización sencilla de código — no es necesario publicar paquetes en un registro.
• Historial único de commits — facilita la depuración y la auditoría.

Sin embargo, un monorepositorio requiere disciplina: sin una estructura clara, rápidamente se convierte en un "vertedero". Go, con su estricto sistema de módulos (Go Modules), proporciona excelentes herramientas para organizar dicho repositorio.

Estructura de directorios en un monorepositorio Go

Una estructura correcta es la base del éxito. Veamos la organización recomendada para un monorepositorio en Go:

my-monorepo/├── apps/                    # Aplicaciones (servicios, utilidades CLI)│   ├── api-gateway/│   │   ├── cmd/│   │   │   └── main.go│   │   ├── internal/│   │   ├── go.mod│   │   └── go.sum│   ├── auth-service/│   │   └── ...│   └── user-service/│       └── ...├── libs/                    # Bibliotecas comunes│   ├── common/│   │   ├── logger.go│   │   ├── config.go│   │   ├── go.mod│   │   └── go.sum│   └── models/│       ├── user.go│       ├── go.mod│       └── go.sum├── scripts/                 # Scripts de compilación, despliegue│   ├── build.sh│   └── deploy.sh├── docs/                    # Documentación├── .github/                 # Configuraciones CI/CD│   └── workflows/│       └── ci.yml├── go.work                  # Archivo Workspace (Go 1.18+)├── Makefile                 # Comandos comunes├── README.md└── .gitignore

Elementos clave de la estructura:

• apps/ — contiene aplicaciones ejecutables (servicios, utilidades). Cada aplicación es un módulo Go independiente con su propio go.mod.
• libs/ — bibliotecas comunes que se reutilizan entre aplicaciones.
• go.work — archivo workspace que permite trabajar con todos los módulos localmente sin publicar cambios.

Trabajo con Go Modules en un monorepositorio

A partir de Go 1.18, se agregó soporte para workspaces (go.work). Esto resuelve el problema del desarrollo local cuando los módulos dependen unos de otros. Veamos un ejemplo de configuración.

Creemos un archivo go.work en la raíz del monorepositorio:

go 1.21

use (    ./apps/api-gateway    ./apps/auth-service    ./libs/common    ./libs/models)

Ahora, durante el desarrollo local, Go utilizará las versiones locales de los módulos, en lugar de las publicadas. Esto es fundamental para una iteración rápida.

Ejemplo de dependencia en apps/auth-service/go.mod:

module github.com/company/auth-service

go 1.21

require (    github.com/company/libs/common v0.0.0    github.com/company/libs/model
```